如何設計才可以讓系統從未分庫分錶動態切換到分庫分錶上？
停機遷移方案 我先給你說一個最low 的方案，就是很簡單，大傢伙兒凌晨12 點開始運維，網站或者app 掛個公告，說0 點到早上6 點進行運維，無法訪問。 接著到0點停機，系統停掉，沒有流量寫入了，此時老的單庫單表數據庫靜止了。 然後你之前得寫好一個 導數的一次性工具 ，此時直接跑起來，然後將單庫單表的數據嘩嘩嘩讀出來，寫到分庫分錶裡面去。 導數完了之後，就ok 了，修改系統的數據庫連接配置啥的，包括可能代碼和SQL 也許有修改，那你就用最新的代碼，然後直接啟動連到新的分庫分錶上去。 驗證一下，ok了，完美，大家伸個懶腰，看看看凌晨4 點鐘的北京夜景，打個滴滴回家吧。 但是這個方案比較low，誰都能幹，我們來看看高大上一點的方案。 雙寫遷移方案 這個是我們常用的一種遷移方案，比較靠譜一些，不用停機，不用看北京凌晨4 點的風景。 簡單來說，就是在線上系統裡面，之前所有寫庫的地方，增刪改操作， 除了對老庫增刪改，都加上對新庫的增刪改 ，這就是所謂的 雙寫 ，同時寫倆庫，老庫和新庫。 然後 系統部署 之後，新庫數據差太遠，用之前說的導數工具，跑起來讀老庫數據寫新庫，寫的時候要根據gmt_modified這類字段判斷這條數據最後修改的時間，除非是讀出來的數據在新庫裡沒有，或者是比新庫的數據新才會寫。 簡單來說，就是不允許用老數據覆蓋新數據。 導完一輪之後，有可能數據還是存在不一致，那麼就程序自動做一輪校驗，比對新老庫每個表的每條數據，接著如果有不一樣的，就針對那些不一樣的，從老庫讀數據再次寫。 反复循環，直到兩個庫每個表的數據都完全一致為止。 接著當數據完全一致了，就ok 了，基於僅僅使用分庫分錶的最新代碼，重新部署一次，不就僅僅基於分庫分錶在操作了麼，還沒有幾個小時的停機時間，很穩。 所以現在基本玩兒數據遷移之類的，都是這麼幹的。