分庫分表“實踐”大全

摘要：這樣的分表適合需要對數據做歸檔處理，比如系統默認只提供近三個月曆史數據的查詢功能，這樣也方便操作。一旦分表上線後所有的數據寫入、查詢都是針對於分表的，所以原有大表內的數據必須得遷移到分表裏，不然對業務的影響極大。

分庫分表是個蛋疼的過程，需要考慮數據遷移、數據同步、數據切分等多個工作項，項目bug會持續到天荒地老。網絡上搜索到的文章，往往有些錯誤的觀點，只有調研，沒有實踐。在早些年，我就走過這方面的彎路。本篇文章亦爲實踐後的產出，有很大的參考價值

其餘相關文章，參見：

“分庫分表" ？選型和流程要慎重，否則會失控

本篇文章從廣度上說明了分庫分表組件的選型和流程，以及其優缺點。尤其對比了驅動層和代理(proxy)層的中間件特點。

如果你面試的時候有如此見解，包面試官滿意。

數據庫中間件詳解（精品長文）

接近2w字的數據庫中間件介紹，主要說明了一箇中間件要關注的功能和要點。如果你在做一箇中間件，一定會對這些功能進行裁剪。

本文也能考察是否做過數據庫中間件，而不僅僅用過。

現實中的路由規則，可能比你想象中複雜的多

本文以一個現實中複雜的路由規則，舉例說明了許多企業複雜的數據路由。這並不是簡單的mod，range，一致性hash能夠解決的問題，通常都有它的歷史原因。

如果你的項目是新的，可以考慮怎麼去規避它。

”MySQL官方驅動“主從分離的神祕面紗（掃盲篇）

如果你想要一個簡單的數據庫中間件，不需要分庫分表，但是需要讀寫分離和failover，mysql官方驅動就可以完成這個過程，非常推薦。

非規範SQL的sharding-jdbc實踐

針對shardingjdbc組件的一些實踐經驗。其實，我個人推薦使用資源佔用（人力、服務器）較少的驅動層方案。

本文提到了一些不支持的特性，這是尤其要關注的。

背景

前不久發過兩篇關於分表的文章：

從標題可以看得出來，當時我們只做了分表；還是由於業務發展，截止到現在也做了分庫，目前看來都還比較順利，所以藉着腦子還記得清楚來一次覆盤。

先來回顧下整個分庫分表的流程如下：

整個過程也很好理解，基本符合大部分公司的一個發展方向。

很少會有業務一開始就會設計爲分庫分表，雖說這樣會減少後續的坑，但部分公司剛開始都是以業務爲主。

直到業務發展到單表無法支撐時，自然而然會考慮分表甚至分庫的事情。

於是本篇會作一次總結，之前提過的內容可能會再重複一次。

分表

首先討論下什麼樣的情況下適合分表？

根據我的經驗來看，當某張表的數據量已經達到千萬甚至上億，同時日增數據量在 2% 以上。

當然這些數字並不是絕對的，最重要的還是對這張表的寫入和查詢都已經影響到正常業務執行，比如查詢速度明顯下降，數據庫整體 IO 居高不下等。

而談到分表時我們着重討論的還是水平分表；

也就是將一張大表數據通過某種路由算法將數據儘可能的均勻分配到 N 張小表中。

Range

而分表策略也有好幾種，分別適用不同的場景。

首先第一種是按照範圍劃分，比如我們可以將某張表的創建時間按照日期劃分存爲月表；也可以將某張表的主鍵按照範圍劃分，比如【1~10000】在一張表，【10001~20000】在一張表，以此類推。

這樣的分表適合需要對數據做歸檔處理，比如系統默認只提供近三個月曆史數據的查詢功能，這樣也方便操作；只需要把三月之前的數據單獨移走備份保存即可）。

這個方案有好處也有弊端：

好處是自帶水平擴展，不需要過多幹預。
缺點是可能會出現數據不均勻的情況（比如某個月請求暴增）。

Hash

按照日期這樣的範圍分表固然簡單，但適用範圍還是比較窄；畢竟我們大部分的數據查詢都不想帶上時間。

比如某個用戶想查詢他產生的所有訂單信息，這是很常見的需求。

於是我們分表的維度就得改改，分表算法可以採用主流的 hash+mod 的組合。

這是一個經典的算法，大名鼎鼎的 HashMap 也是這樣來存儲數據。

假設我們這裏將原有的一張大表訂單信息分爲 64 張分表：

這裏的 hash 便是將我們需要分表的字段進行一次散列運算，使得經過散列的數據儘可能的均勻並且不重複。

當然如果本身這個字段就是一個整形並且不重複也可以省略這個步驟，直接進行 Mod 得到分表下標即可。

分表數量選擇

至於這裏的分表數量（64）也是有講究的，具體設爲多少這個沒有標準值，需要根據自身業務發展，數據增量進行預估。

根據我個人的經驗來看，至少需要保證分好之後的小表在業務發展的幾年之內都不會出現單表數據量過大（比如達到千萬級）。

我更傾向於在數據庫可接受的範圍內儘可能的增大這個分表數，畢竟如果後續小表也達到瓶頸需要再進行一次分表擴容，那是非常痛苦的。

目前筆者還沒經歷這一步，所以本文沒有相關介紹。

但是這個數量又不是瞎選的，和 HashMap 一樣，也建議得是 2^n ，這樣可以方便在擴容的時儘可能的少遷移數據。

Range + Hash

當然還有一種思路， Range 和 Hash 是否可以混用。

比如我們一開始採用的是 Hash 分表，但是數據增長巨大，導致每張分表數據很快達到瓶頸，這樣就不得不再做擴容，比如由 64 張表擴容到 256 張。

但擴容時想要做到不停機遷移數據非常困難，即便是停機，那停多久呢？也不好說。

所以我們是否可以在 Mod 分表的基礎上再分爲月表，藉助於 Range 自身的擴展性就不用考慮後續數據遷移的事情了。

這種方式理論可行，但我沒有實際用過，給大家的思路做個參考吧。

煩人的數據遷移

分表規則弄好後其實只是完成了分表的第一步，真正麻煩的是數據遷移，或者說是如何做到對業務影響最小的數據遷移。

除非是一開始就做了分表，所以數據遷移這一步驟肯定是跑不掉的。

下面整理下目前我們的做法供大家參考：

一旦分表上線後所有的數據寫入、查詢都是針對於分表的，所以原有大表內的數據必須得遷移到分表裏，不然對業務的影響極大。
我們估算了對一張 2 億左右的表進行遷移，自己寫的遷移程序，大概需要花 4~5 天的時間才能完成遷移。
意味着這段時間內，以前的數據對用戶是不可見的，顯然這樣業務不能接受。
於是我們做了一個兼容處理：分表改造上線後，所有新產生的數據寫入分表，但對歷史數據的操作還走老表，這樣就少了數據遷移這一步驟。
只是需要在操作數據之前做一次路由判斷，當新數據產生的足夠多時（我們是兩個月時間），幾乎所有的操作都是針對於分表，再從庫啓動數據遷移，數據遷移完畢後將原有的路由判斷去掉。
最後所有的數據都從分表產生和寫入。