資料庫分庫分表的總結

（1）為什麼要分庫分表？（設計高併發系統的時候，資料庫層面該如何設計？）

分表是啥意思？就是把一個表的資料放到多個表中，然後查詢的時候你就查一個表。比如按照使用者id來分表，將一個使用者的資料就放在一個表中。然後操作的時候你對一個使用者就操作那個表就好了。這樣可以控制每個表的資料量在可控的範圍內，比如每個表就固定在200萬以內。

 

分庫是啥意思？就是你一個庫一般我們經驗而言，最多支撐到併發2000，一定要擴容了，而且一個健康的單庫併發值你最好保持在每秒1000左右，不要太大。那麼你可以將一個庫的資料拆分到多個庫中，訪問的時候就訪問一個庫好了。

（2）用過哪些分庫分表中介軟體？不同的分庫分表中介軟體都有什麼優點和缺點？

 比較常見的包括： sharding-jdbc、mycat

sharding-jdbc：噹噹開源的，屬於client層方案。確實之前用的還比較多一些，因為SQL語法支援也比較多，沒有太多限制，而且目前推出到了2.0版本，支援分庫分表、讀寫分離、分散式id生成、柔性事務（最大努力送達型事務、TCC事務）。而且確實之前使用的公司會比較多一些（這個在官網有登記使用的公司，可以看到從2017年一直到現在，是不少公司在用的），目前社群也還一直在開發和維護，還算是比較活躍，個人認為算是一個現在也可以選擇的方案。

 

mycat：基於cobar改造的，屬於proxy層方案，支援的功能非常完善，而且目前應該是非常火的而且不斷流行的資料庫中介軟體，社群很活躍，也有一些公司開始在用了。但是確實相比於sharding jdbc來說，年輕一些，經歷的錘鍊少一些。

 

sharding-jdbc這種client層方案的優點在於不用部署，運維成本低，不需要代理層的二次轉發請求，效能很高，但是如果遇到升級啥的需要各個系統都重新升級版本再發布，各個系統都需要耦合sharding-jdbc的依賴；

 

mycat這種proxy層方案的缺點在於需要部署，自己及運維一套中介軟體，運維成本高，但是好處在於對於各個專案是透明的，如果遇到升級之類的都是自己中介軟體那裡搞就行了。

 

（3）你們具體是如何對資料庫如何進行垂直拆分或水平拆分的？

垂直拆分是指資料表列的拆分，把一張列比較多的表拆分為多張表

 

通常我們按以下原則進行垂直拆分:

1. 把不常用的欄位單獨放在一張表;
2. 把text，blob等大欄位拆分出來放在附表中;
3. 經常組合查詢的列放在一張表中;

垂直拆分更多時候就應該在資料表設計之初就執行的步驟，然後查詢的時候用jion關鍵起來即可;

 

水平拆分是指資料錶行的拆分，表的行數超過200萬行時，就會變慢，這時可以把一張的表的資料拆成多張表來存放。

 

而且這兒還有兩種分庫分表的方式，一種是按照range來分，就是每個庫一段連續的資料，這個一般是按比如時間範圍來的，但是這種一般較少用，因為很容易產生熱點問題，大量的流量都打在最新的資料上了；或者是按照某個欄位hash一下均勻分散，這個較為常用。而且這兒還有兩種分庫分表的方式，一種是按照range來分，就是每個庫一段連續的資料，這個一般是按比如時間範圍來的，但是這種一般較少用，因為很容易產生熱點問題，大量的流量都打在最新的資料上了；或者是按照某個欄位hash一下均勻分散，這個較為常用。

 

(4)如何把系統不停機遷移到分庫分表的？

簡單來說，就是線上上系統裡面，之前所有寫庫的地方，增刪改操作，都除了對老庫增刪改，都加上對新庫的增刪改，這就是所謂雙寫，同時寫倆庫，老庫和新庫。

然後系統部署之後，新庫資料差太遠，用之前說的導數工具，跑起來讀老庫資料寫新庫，寫的時候要根據gmt_modified這類欄位判斷這條資料最後修改的時間，除非是讀出來的資料在新庫裡沒有，或者是比新庫的資料新才會寫。

接著導完一輪之後，有可能資料還是存在不一致，那麼就程式自動做一輪校驗，比對新老庫每個表的每條資料，接著如果有不一樣的，就針對那些不一樣的，從老庫讀資料再次寫。反覆迴圈，直到兩個庫每個表的資料都完全一致為止。

接著當資料完全一致了，就ok了，基於僅僅使用分庫分表的最新程式碼，重新部署一次，不就僅僅基於分庫分表在操作了麼，還沒有幾個小時的停機時間，很穩。所以現在基本玩兒資料遷移之類的，都是這麼幹了。

 

(5)如何設計可以動態擴容縮容的分庫分表方案？

1、設定好幾臺資料庫伺服器，每臺伺服器上幾個庫，每個庫多少個表，推薦是32庫 * 32表，對於大部分公司來說，可能幾年都夠了

2、路由的規則，orderId 模 32 = 庫，orderId / 32 模 32 = 表

3、擴容的時候，申請增加更多的資料庫伺服器，裝好mysql，倍數擴容，4臺伺服器，擴到8臺伺服器，16臺伺服器

4、由dba負責將原先資料庫伺服器的庫，遷移到新的資料庫伺服器上去，很多工具，庫遷移，比較便捷

5、我們這邊就是修改一下配置，調整遷移的庫所在資料庫伺服器的地址

6、重新發布系統，上線，原先的路由規則變都不用變，直接可以基於2倍的資料庫伺服器的資源，繼續進行線上系統的提供服務