當業務數據量非常大，單資料庫無法支撐的時候，有可能是單庫已經寫滿了，也可能資料庫讀寫比較頻繁，已經觸碰到單庫的io瓶頸了，這時就需要考慮分庫。 下麵聊一下該怎麼分庫，如何優化： 剛開始只有資料庫A, 後來又加了資料庫B。 假如數據表都是有時間戳欄位，而且數據查詢條件都帶一個時間戳欄位，這樣我們可以根 ...
當業務數據量非常大，單資料庫無法支撐的時候，有可能是單庫已經寫滿了，也可能資料庫讀寫比較頻繁，已經觸碰到單庫的io瓶頸了，這時就需要考慮分庫。
下麵聊一下該怎麼分庫，如何優化：
剛開始只有資料庫A, 後來又加了資料庫B。
假如數據表都是有時間戳欄位，而且數據查詢條件都帶一個時間戳欄位，這樣我們可以根據數據創建的時間範圍來分庫，比如給資料庫按年份命名db_2019， 到2020年新生成一個庫db_2020， 在業務端進行數據讀寫操作時，先根據時間戳條件獲取到年份，然後選擇相應年份的資料庫進行操作。
但上面這種方式只適合這種特定的業務場景，而且這種方式，可能舊數據很少讀取，新數據會比較頻繁讀取，會導致不同資料庫負載是不均勻的。所以會不會有更好的分片方式呢？ 答案是肯定的。幾乎任何一張表都會有鍵欄位，假如鍵值是數字類型，可以鍵值與資料庫數量取模的方式進行分片，比如鍵值是100，資料庫數量是2， 那麼100%2得到0，就應該存儲到索引為0的資料庫。假如鍵值是字元串呢，可以通過crc32(value)算出一個數字，然後再通過數字取模的方式得到相應的資料庫。
假如在使用過程中，資料庫又不夠用了，需要再擴容，怎麼辦？
停服，根據新的分片邏輯進行數據遷移，起服上線新的分片邏輯。沒毛病，假如業務允許停機一段時間， 這也是一種穩妥方式。假如業務不允許停機，或只允許停機很短的時間，這時該如何資料庫擴容呢，或者說該如何平滑地進行資料庫遷移而不影響業務呢？
可以通過下麵步驟來
方案一：
- 修改寫資料庫邏輯：對需要遷移的數據，進行雙寫（寫原資料庫和要遷往的資料庫）
- 寫一個遷移腳本：從原資料庫遷數據到目標資料庫
- 校驗原資料庫是否跟跟目標資料庫數據一致（在遷移的瞬間可能發生了原資料庫刪除了數據，而目標資料庫依然寫入），刪掉目標資料庫多餘的數據。
- 修改資料庫分片邏輯，去掉雙寫邏輯
- 刪掉各個資料庫冗餘的數據
若資料庫雙倍分庫擴容有更好方案
方案二：
- 原資料庫和要遷往的資料庫設計成雙主同步
- 修改資料庫分片邏輯
- 刪掉各個資料庫冗餘的數據
後面找個時間再補充一些圖表，以便讀者能更直觀得理解。
還有一些問題：
問題一：假如方案一中，進行雙寫的時候一個寫成功，一個寫失敗，該如何處理？
問題二：分庫後，如何分頁查詢數據？
後面會再寫一篇較大篇幅的文章分析如何跨資料庫分頁查詢數據。
