目前很多互聯網系統都存在單表數據量過大的問題，這就降低了查詢速度，影響了客戶體驗。為了提高查詢速度，我們可以優化sql語句，優化表結構和索引，不過對那些百萬級千萬級的數據庫表，即便是優化過后，查詢速度還是滿足不了要求。這時候我們就可以通過分表降低單次查詢數據量，從而提高查詢速度，一般分表的方式有兩種：水平拆分和垂直拆分，兩者各有利弊，適用于不同的情況。

水平拆分?
水平拆分是指數據表行的拆分，表的行數超過200萬行時，就會變慢，這時可以把一張的表的數據拆成多張表來存放。?
這里寫圖片描述?
?
通常情況下，我們使用取模的方式來進行表的拆分;比如一張有400W的用戶表users，為提高其查詢效率我們把其分成4張表users1，users2，users3，users4?
通過用ID取模的方法把數據分散到四張表內Id%4+1 = [1,2,3,4]?
然后查詢,更新,刪除也是通過取模的方法來查詢。

例：QQ的登錄表。假設QQ的用戶有100億，如果只有一張表，每個用戶登錄的時候數據庫都要從這100億中查找，會很慢很慢。如果將這一張表分成100份，每張表有1億條，就小了很多，比如qq0,qq1,qq1…qq99表。

用戶登錄的時候，可以將用戶的id%100，那么會得到0-99的數，查詢表的時候，將表名qq跟取模的數連接起來，就構建了表名。比如123456789用戶，取模的89，那么就到qq89表查詢，查詢的時間將會大大縮短。

另外部分業務邏輯也可以通過地區，年份等字段來進行歸檔拆分;進行拆分后的表，只能滿足部分查詢的高效查詢需求，這時我們就要在產品策劃上，從界面上約束用戶查詢行為。比如我們是按年來進行歸檔拆分的,這個時候在頁面設計上就約束用戶必須要先選擇年,然后才能進行查詢;在做分析或者統計時，由于是自己人的需求,多點等待其實是沒關系的,并且并發很低,這個時候可以用union把所有表都組合成一張視圖來進行查詢,然后再進行查詢。

水平拆分的優點：?
◆表關聯基本能夠在數據庫端全部完成；?
◆不會存在某些超大型數據量和高負載的表遇到瓶頸的問題；?
◆應用程序端整體架構改動相對較少；?
◆事務處理相對簡單；?
◆只要切分規則能夠定義好，基本上較難遇到擴展性限制；

水平切分的缺點：?
◆切分規則相對更為復雜，很難抽象出一個能夠滿足整個數據庫的切分規則；?
◆后期數據的維護難度有所增加，人為手工定位數據更困難；?
◆應用系統各模塊耦合度較高，可能會對后面數據的遷移拆分造成一定的困難。

垂直拆分?
垂直拆分是指數據表列的拆分，把一張列比較多的表拆分為多張表。表的記錄并不多，但是字段卻很長，表占用空間很大，檢索表的時候需要執行大量的IO，嚴重降低了性能。這時需要把大的字段拆分到另一個表，并且該表與原表是一對一的關系。?
這里寫圖片描述?

通常我們按以下原則進行垂直拆分:?
1，把不常用的字段單獨放在一張表;,?
2，把text，blob等大字段拆分出來放在附表中;?
3，經常組合查詢的列放在一張表中;

例如學生答題表tt：有如下字段：?
Id name 分數 題目 回答?
其中題目和回答是比較大的字段，id name 分數比較小。

如果我們只想查詢id為8的學生的分數：select 分數 from tt where id = 8;雖然知識查詢分數，但是題目和回答這兩個大字段也是要被掃描的，很消耗性能。但是我們只關心分數，并不想查詢題目和回答。這就可以使用垂直分割。我們可以把題目單獨放到一張表中，通過id與tt表建立一對一的關系，同樣將回答單獨放到一張表中。這樣我們插敘tt中的分數的時候就不會掃描題目和回答了。

垂直切分的優點?
◆ 數據庫的拆分簡單明了，拆分規則明確；?
◆ 應用程序模塊清晰明確，整合容易；?
◆ 數據維護方便易行，容易定位；

垂直切分的缺點?
◆ 部分表關聯無法在數據庫級別完成，需要在程序中完成；?
◆ 對于訪問極其頻繁且數據量超大的表仍然存在性能平靜，不一定能滿足要求；?
◆ 事務處理相對更為復雜；?
◆ 切分達到一定程度之后，擴展性會遇到限制；?
◆ 過讀切分可能會帶來系統過渡復雜而難以維護。

?

?

轉載于:https://www.cnblogs.com/qhorse/p/10483139.html

總結

以上是生活随笔為你收集整理的MYSQL水平拆分与垂直拆分的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。