一 概述
分庫分表的順序應該是先垂直分，後水平分。單個庫太大 如果是因爲表多而數據多，應使用垂直切分，根據業務切分成不同的庫。
如果是因爲單張表的數據量太大，需要用水平切分，即把表的數據按某種規則切分成多張表，甚至多個庫上的多張表。
二、分庫
當單庫太大，業務上可能會遇到如下問題：
1.單個數據庫處理能力有限；
2.單庫所在服務器上磁盤空間不足；
3.單庫上操作的IO瓶頸 ；
可以採取的解決方案：切分成更多更小的庫，提高數據庫寫入能力。
1.垂直分庫
垂直分庫針對一個系統中的不同業務進行拆分，按照業務拆分到不同服務器上，例如交易按用戶，商品，訂單來拆分分別放到不同服務器上可以提高單機服務器處理能力，避免放在一個單機上出現性能瓶頸。在高併發場景下，垂直分庫一定程度上能夠突破IO、連接數及單機硬件資源的瓶頸。
三、分表
當單表太大，業務上可能會碰到如下問題：
1.影響增刪改查；
2.索引膨脹，查詢超時
可以採取的解決方案：切分成多個數據集更小的表。減少數據查詢所需要的時間，提高數據庫的吞吐。
1.垂直分表
也就是“大表拆小表”，基於列字段進行的。一般是表中的字段較多，將不常用的， 數據較大，長度較長（比如text類型字段）的拆分到“擴展表“。 主要針對那種幾百列的大表，避免查詢時數據量太大造成的“跨頁”問題。
2.水平分表
針對數據量巨大的單張表（比如訂單表），按照某種規則（RANGE,HASH取模等），切分到多張表裏面去。 但是這些表還是在同一個庫中。仍然無法解決庫的數據訪問存儲出現的IO瓶頸。
四、分庫分表
當數據庫面臨高併發訪問壓力，同時面對海量數據存儲，需要對數據庫採用分庫並採用分表，從而提高併發處理和查詢效率。
-
水平分庫分表
將單張表的數據切分到多個服務器上去，每個服務器具有相應的庫與表，只是表中數據集合不同。 水平分庫分表能夠有效的緩解單機和單庫的性能瓶頸和壓力，突破IO、連接數、硬件資源等的瓶頸。
2.水平分庫分表切分規則
（1）RANGE：從0到10000一個表，10001到20000一個表；
（2） hash取模：一個商場系統，一般都是將用戶，訂單作爲主表，然後將和它們相關的作爲附表，這樣不會造成跨庫事務之類的問題。 取用戶id，然後hash取模，分配到不同的數據庫上。
（3）地理區域：比如按照華東，華南，華北這樣來區分業務，很多雲服務應該是這樣。
（4）時間：按照時間切分，比如將6個月前或者一年前的數據切出去放到另外的一張表，時間長的表的數據被查詢的概率變小是冷數據，實現“冷熱數據分離”。
3.一種分庫分表路由策略：
中間變量=user_id%(庫數量x每個庫的表數量）；
庫=取整（中間變量/每個庫的表數量）；
表=中間變量%每個庫的表數量。
五、分庫分表後面臨的問題
1.分庫分表後，就成了分佈式事務了。如果依賴數據庫本身的分佈式事務管理功能去執行事務，會犧牲系統性能； 如果由應用程序去協助控制，會增加程序邏輯複雜度。
2.由於記錄被切分到不同的庫與不同的表當中，難以進行多表關聯查詢，還必須指定路由字段進行數據查詢。
3.分庫分表後對系統進一步擴容變得非常不方便需要重新數據遷移。