一、分庫分表原因：
關係型數據庫本身比較容易成爲系統瓶頸，單機存儲容量、連接數、處理能力都有限。當單表的數據量達到1000W或100G以後，由於查詢維度較多，即使添加從庫、優化索引，做很多操作時性能仍下降嚴重。此時就要考慮對其進行切分了，切分的目的就在於減少數據庫的負擔，縮短查詢時間。
數據庫分佈式核心內容無非就是數據切分（Sharding），以及切分後對數據的定位、整合。數據切分就是將數據分散存儲到多個數據庫中，使得單一數據庫中的數據量變小，通過擴充主機的數量緩解單一數據庫的性能問題，從而達到提升數據庫操作性能的目的。
數據切分根據其切分類型，可以分爲兩種方式：垂直（縱向）切分和水平（橫向）切分
二、垂直與水平拆分
-
垂直拆分
- 垂直分表：也就是“大表拆小表”，基於列字段進行的。一般是表中的字段較多，將不常用的， 數據較大，長度較長（比如text類型字段）的拆分到“擴展表“。 一般是針對那種上百列的大表，也避免查詢時，數據量太大造成的數據庫底層的“跨頁”問題。
- 垂直分庫：垂直分庫針對的是一個系統中的不同業務進行拆分，比如用戶User一個庫，商品Producet一個庫，訂單Order一個庫。 切分後，要放在多個服務器上，而不是一個服務器上。爲什麼？ 我們想象一下，一個購物網站對外提供服務，會有用戶，商品，訂單等的CRUD。沒拆分之前， 全部都是落到單一的庫上的，這會讓數據庫的單庫處理能力成爲瓶頸。按垂直分庫後，如果還是放在一個數據庫服務器上， 隨着用戶量增大，這會讓單個數據庫的處理能力成爲瓶頸，還有單個服務器的磁盤空間，內存，tps等非常吃緊。 所以我們要拆分到多個服務器上，這樣上面的問題都解決了，以後也不會面對單機資源問題。
-
水平拆分
- 水平分表：針對數據量巨大的單張表（比如訂單表），按照某種規則（RANGE,HASH取模等），切分到多張表裏面去。 但是這些表還是在同一個庫中，所以庫級別的數據庫操作還是有IO瓶頸。不建議採用。
- 水平分庫：將單張表的數據切分到多個服務器上去，每個服務器具有相應的庫與表，只是表中數據集合不同。 水平分庫分表能夠有效的緩解單機和單庫的性能瓶頸和壓力，突破IO、連接數、硬件資源等的瓶頸。
-
水平分庫分表切分規則：
- 按號段分：user_id爲區分，1～1000的對應DB1，1001～2000的對應DB2，以此類推；
優點：可部分遷移
缺點：數據分佈不均 - HASH取模分：假設有用戶表user,將其分成3個表user0,user1,user2.路由規則是對3取模,當uid=1時,對應到的是user1,uid=2時,對應的是user2。
優點：數據分佈均勻
缺點：數據遷移的時候麻煩，不能按照機器性能分攤數據 - 在認證庫中保存數據庫配置：建立一個DB，這個DB單獨保存user_id到DB的映射關係，每次訪問數據庫的時候都要先查詢一次這個數據庫，以得到具體的DB信息，然後才能進行我們需要的查詢操作。
優點：靈活性強，一對一關係
缺點：每次查詢之前都要多一次查詢，性能大打折扣 - 其他方式：
1）按照地理區域：比如按照華東，華南，華北這樣來區分業務。
2）按照時間切分，就是將6個月前，甚至一年前的數據切出去放到另外的一張表，因爲隨着時間流逝，這些表的數據被查詢的概率變小，所以沒必要和“熱數據”放在一起，這個也是“冷熱數據分離”。
三、垂直和水平拆分優缺點：
-
垂直切分
優點：
- 解決業務系統層面的耦合，業務清晰
- 與微服務的治理類似，也能對不同業務的數據進行分級管理、維護、監控、擴展等
- 高併發場景下，垂直切分一定程度的提升IO、數據庫連接數、單機硬件資源的瓶頸
缺點：
- 部分表無法join，只能通過接口聚合方式解決，提升了開發的複雜度
- 分佈式事務處理複雜
- 依然存在單表數據量過大的問題（需要水平切分）
-
水平切分
優點：
- 不存在單庫數據量過大、高併發的性能瓶頸，提升系統穩定性和負載能力
- 應用端改造較小，不需要拆分業務模塊
缺點：
- 跨分片的事務一致性難以保證
- 跨庫的join關聯查詢性能較差
- 數據多次擴展難度和維護量極大