mysql分庫分表

一概述

分庫分表的順序應該是先垂直分，後水平分。單個庫太大如果是因為表多而資料多，應使用垂直切分，根據業務切分成不同的庫。

如果是因為單張表的資料量太大，需要用水平切分，即把表的資料按某種規則切分成多張表，甚至多個庫上的多張表。

二、分庫

當單庫太大，業務上可能會遇到如下問題：

1.單個資料庫處理能力有限；

2.單庫所在伺服器上磁碟空間不足；

3.單庫上操作的io瓶頸；

1.垂直分庫

垂直分庫針對乙個系統中的不同業務進行拆分，按照業務拆分到不同伺服器上，例如交易按使用者，商品，訂單來拆分分別放到不同伺服器上可以提高單機伺服器處理能力，避免放在乙個單機上出現效能瓶頸。在高併發場景下，垂直分庫一定程度上能夠突破io、連線數及單機硬體資源的瓶頸。

三、分表

當單錶太大，業務上可能會碰到如下問題：

1.影響增刪改查；

2.索引膨脹，查詢超時

可以採取的解決方案：切分成多個資料集更小的表。減少資料查詢所需要的時間，提高資料庫的吞吐。

1.垂直分表

也就是「大表拆小表」，基於列欄位進行的。一般是表中的字段較多，將不常用的，資料較大，長度較長（比如text型別字段）的拆分到「擴充套件表「。主要針對那種幾百列的大表，避免查詢時資料量太大造成的「跨頁」問題。

2.水平分表

針對資料量巨大的單張表（比如訂單表），按照某種規則（range,hash取模等），切分到多張表裡面去。但是這些表還是在同乙個庫中。仍然無法解決庫的資料訪問儲存出現的io瓶頸。

四、分庫分表

當資料庫面臨高併發訪問壓力，同時面對海量資料儲存，需要對資料庫採用分庫並採用分表，從而提高併發處理和查詢效率。

水平分庫分表

將單張表的資料切分到多個伺服器上去，每個伺服器具有相應的庫與表，只是表中資料集合不同。水平分庫分表能夠有效的緩解單機和單庫的效能瓶頸和壓力，突破io、連線數、硬體資源等的瓶頸。

2.水平分庫分表切分規則

（1）range：從0到10000乙個表，10001到20000乙個表；

（3）地理區域：比如按照華東，華南，華北這樣來區分業務，很多雲服務應該是這樣。

3.一種分庫分表路由策略：

中間變數=user_id%(庫數量x每個庫的表數量）；

庫=取整（中間變數/每個庫的表數量）；

表=中間變數%每個庫的表數量。

五、分庫分表後面臨的問題

1.分庫分表後，就成了分布式事務了。如果依賴資料庫本身的分布式事務管理功能去執行事務，會犧牲系統效能；如果由應用程式去協助控制，會增加程式邏輯複雜度。

2.由於記錄被切分到不同的庫與不同的表當中，難以進行多表關聯查詢，還必須指定路由字段進行資料查詢。

3.分庫分表後對系統進一步擴容變得非常不方便需要重新資料遷移。