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