一直以來個人都對資料表的垂直分表有個誤區，因為我覺得乙個表如果要垂直分表的話，本來是乙個千萬級表，現在兩個或者多個，這樣不是增加了大表的數量嗎？
還有就是想著select不需要的行可以解決這樣的問題嗎？這個先解答一下，因為mysql本身是行記錄格式，也就是說就算select * 或者select 具體字段的話，是不會區分具體列的，當然這個也不是沒有意義，更多的是規範，而且減少不必要的網路傳輸資料。具體的行記錄格式之前一篇部落格說過錶空間結構。
在這裡我可能在個人的知識範疇內說幾點，如果有不同的看法，或者發現錯誤，希望大家提出。
這個主要是大字段的拆分，因為字段本身可能非常大，超出行的可變長度，這個是在使用varchar可變型別情況下，因為資料庫的行格式會儲存變長字段的長度，而這個儲存的字段最多就2位元組，這樣的話可變長度最多就可以達到65535，達到這個長度的話，計算了一下，一行資料的可變長度的列總和不超過64k左右（沒精準算），超過的話會溢位行到blob頁，這裡還衍生了個問題，因為頁儲存就16k，而一行資料就遠遠超出，這樣就失去了b+樹的意義了，所以一般mysql會拆分字首儲存額外資料到額外頁，一頁保持至少兩行資料。
mysql的查詢快取具體是根據查詢語句來的，這裡具體可以去看《高效能mysql》一書，大概表達的意思是查詢語句不能有變數或者函式，例如current_timestamp之類的，這樣不會有快取，有點跑偏了。這裡的意思是，垂直拆分表後，有些欄位是常修改的，例如使用者的個性簽名之類的，而更新操作會讓查詢快取無效，所以垂直拆分會優化查詢效率。
頁是什麼呢？頁應該算作資料庫的儲存最小單位，在mysql中例如，insert_buffer_pool，aio，索引查詢都是以頁為單位，首先垂直拆分表的話，隨著欄位的減少，每頁裡面的資料行也會增多，理論上頁裡面的資料行越多效能越好。
例如圖中所示假如未分表之前頁分布是這樣的，如果要查詢id=1和id=9的話可能是需要兩次索引查詢，兩次磁碟io，這裡為啥說頁1和頁3呢，因為非同步io的可能性，innodb不會去等待第乙個掃瞄結果，而是先掃瞄，然後去取資料，例如如果是id=1和id=6，根據page判斷資料是相鄰頁，因為頁是順序儲存的，所以會合併也就一次磁碟io取出兩頁資料。
像上面這樣，頁裡的行數增多，就可以減少一部分磁碟的io，這樣也就增加了查詢效率。
寫入和更新其實還是頁的問題，同樣的問題，頁的減少，就會影響髒頁的重新整理，insert_buffer的mergy，這樣都會影響iops，如果頁的減少，資料也會儲存更有順序性，對於寫入與讀取的話，順序讀比離散讀要快，效能也能得到提公升。
垂直分表水平分表
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 分表技術 表的結構不能變 分表技術有 水平分割和垂直分割 當一張越來越大時候，即使新增索引還慢的話，我們可以使用分表 以qq使用者表來具體的說明...
mysql垂直分表好處 水平 垂直拆表的好處
1，水平分表 一條記錄一條記錄切斷分出來！2,垂直分表 把常用的 不常用的，欄位很長的拆出來！目前很多網際網路系統都存在單錶資料量過大的問題，這就降低了查詢速度，影響了客戶體驗。為了提高查詢速度，我們可以優化sql語句，優化表結構和索引，不過度那些百萬級，千萬級的資料庫表，即便優化過後，查詢速度還是...
水平和垂直分表
原文 1，水平分割 例 qq的登入表。假設qq的使用者有100億，如果只有一張表，每個使用者登入的時候資料庫都要從這100億中查詢，會很慢很慢。如果將這一張表分成100份，每張表有1億條，就小了很多，比如qq0,qq1,qq1.qq99表。使用者登入的時候，可以將使用者的id 100，那麼會得到0 ...