1 面試題
現在有一個未分庫分表的系統，未來要分庫分表，如何設計才可以讓系統從未分庫分表動态切換到分庫分表上？
2 考點分析
你現在已經明白為啥要分庫分表了，你也知道常用的分庫分表中間件了，你也設計好你們如何分庫分表的方案了（水準拆分、垂直拆分、分表），那問題來了，你接下來該怎麼把你那個單庫單表的系統給遷移到分庫分表上去？
是以這都是一環扣一環的，就是看你有沒有全流程經曆過這個過程
假設，你現有一個單庫單表系統線上上跑
單表有600萬資料,3個庫,每個庫裡分了4個表,每個表要放50萬的資料量
假設你已經選擇了一個分庫分表的資料庫中間件，sharding-jdbc/mycat，都可以
你怎麼把線上系統平滑地遷移到分庫分表上面去
sharding-jdbc：自己上官網，找一個官網最基本的例子，自己寫一下，試一下，跑跑看，是非常簡單的
mycat：自己上官網，找一個官網最基本的例子，自己寫一下，試一下看看1個小時以内就可以搞定了
3 解決方案
這個其實從low到高大上有好幾種方案，我們都玩兒過，我都給你說一下
3.1 停機遷移方案
最low的方案，就是很簡單，大家夥兒淩晨12點開始運維，網站或者app挂個公告，說0點到早上6點進行運維，無法通路~
接着到0點，停機，系統停掉，沒有流量寫入了，此時老的單庫單表資料庫靜止了
然後你之前得寫好一個導資料的一次性工具，此時直接跑起來，然後将單庫單表的資料嘩讀出來，寫到分庫分表裡
導數完後，就ok了，修改系統的資料庫連接配接配置啥的，包括可能代碼和SQL也許有修改，那你就用最新的代碼，然後直接啟動連到新的分庫分表上去。
驗證一下，ok了，完美，大家伸個懶腰，看看看淩晨4點鐘的北京夜景，打個滴滴回家吧
長時間停機分庫分表
但是這個方案比較low，誰都能幹，我們來看看高大上一點的方案
3.2 雙寫遷移方案
常用的一種遷移方案，比較靠譜，不用停機，不用看淩晨4點的風景
就是線上上系統，之前所有寫庫的地方，增删改操作，除了對舊庫增删改，都加上對新庫的增删改，這就是所謂雙寫 — 同時寫倆庫(舊庫和新庫)
然後系統部署後，新庫資料差太遠，用之前說的導數工具，跑起來讀舊庫資料寫新庫，寫的時候要根據gmt_modified這類字段判斷這條資料最後修改的時間，除非是讀出來的資料在新庫沒有，或者是比新庫的資料新才會寫,即不允許用舊資料覆寫新資料!
接着導完一輪後，有可能資料還是不一緻，那麼就程式自動做一輪校驗
對比新舊庫每個表的每條資料，接着如果有不一樣的，就針對那些不一樣的，從舊庫讀資料再次寫。
反複循環，直到兩個庫每個表的資料都完全一緻為止。
接着當資料完全一緻了，就ok了，基于僅僅使用分庫分表的最新代碼，重新部署一次，不就僅僅基于分庫分表在操作了麼，還沒有幾個小時的停機時間，很穩。是以現在基本玩資料遷移之類的，都是這麼幹了。
不停機雙寫方案
