一、分庫分表原因：

關系型資料庫本身比較容易成為系統瓶頸，單機存儲容量、連接配接數、處理能力都有限。當單表的資料量達到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個月前，甚至一年前的資料切出去放到另外的一張表，因為随着時間流逝，這些表的資料被查詢的機率變小，是以沒必要和“熱資料”放在一起，這個也是“冷熱資料分離”。

優點：

缺點：

優點：

缺點：