停機擴容（不推薦）
這個方案就跟停機遷移一樣，步驟幾乎一緻，唯一的一點就是那個導數的工具，是把現有庫表的資料抽出來慢慢倒入到新的庫和表裡去。但是最好别這麼玩兒，有點不太靠譜，因為既然分庫分表就說明資料量實在是太大了，可能多達幾億條，甚至幾十億，你這麼玩兒，可能會出問題。
從單庫單表遷移到分庫分表的時候，資料量并不是很大，單表最大也就兩三千萬。那麼你寫個工具，多弄幾台機器并行跑，1小時資料就導完了。這沒有問題。
如果 3 個庫 + 12 個表，跑了一段時間了，資料量都 1~2 億了。光是導 2 億資料，都要導個幾個小時，6 點，剛剛導完資料，還要搞後續的修改配置，重新開機系統，測試驗證，10 點才可以搞完。是以不能這麼搞。
優化後的方案
一開始上來就是 32 個庫，每個庫 32 個表，那麼總共是 1024 張表。
我可以告訴各位同學，這個分法，第一，基本上國内的網際網路肯定都是夠用了，第二，無論是并發支撐還是資料量支撐都沒問題。
每個庫正常承載的寫入并發量是 1000，那麼 32 個庫就可以承載32 * 1000 = 32000 的寫并發，如果每個庫承載 1500 的寫并發，32 * 1500 = 48000 的寫并發，接近 5萬/s 的寫入并發，前面再加一個MQ，削峰，每秒寫入 MQ 8 萬條資料，每秒消費 5 萬條資料。
有些除非是國内排名非常靠前的這些公司，他們的最核心的系統的資料庫，可能會出現幾百台資料庫的這麼一個規模，128個庫，256個庫，512個庫。
1024 張表，假設每個表放 500 萬資料，在 MySQL 裡可以放 50 億條資料。
每秒的 5 萬寫并發，總共 50 億條資料，對于國内大部分的網際網路公司來說，其實一般來說都夠了。
談分庫分表的擴容，第一次分庫分表，就一次性給他分個夠，32 個庫，1024 張表，可能對大部分的中小型網際網路公司來說，已經可以支撐好幾年了。
一個實踐是利用
32 * 32
來分庫分表，即分為 32 個庫，每個庫裡一個表分為 32 張表。一共就是 1024 張表。根據某個 id 先根據 32 取模路由到庫，再根據 32 取模路由到庫裡的表。
| orderId | id % 32 (庫) | id / 32 % 32 (表) |
|---|---|---|
| 259 | 3 | 8 |
| 1189 | 5 | 5 |
| 352 | 11 | |
| 4593 | 17 | 15 |
剛開始的時候，這個庫可能就是邏輯庫，建在一個資料庫上的，就是一個mysql伺服器可能建了 n 個庫，比如 32 個庫。後面如果要拆分，就是不斷在庫和 mysql 伺服器之間做遷移就可以了。然後系統配合改一下配置即可。
比如說最多可以擴充到32個資料庫伺服器，每個資料庫伺服器是一個庫。如果還是不夠？最多可以擴充到 1024 個資料庫伺服器，每個資料庫伺服器上面一個庫一個表。因為最多是1024個表。
這麼搞，是不用自己寫代碼做資料遷移的，都交給 dba 來搞好了，但是 dba 确實是需要做一些庫表遷移的工作，但是總比你自己寫代碼，然後抽資料導資料來的效率高得多吧。
哪怕是要減少庫的數量，也很簡單，其實說白了就是按倍數縮容就可以了，然後修改一下路由規則。
這裡對步驟做一個總結：
- 設定好幾台資料庫伺服器，每台伺服器上幾個庫，每個庫多少個表，推薦是 32庫 * 32表，對于大部分公司來說，可能幾年都夠了。
- 路由的規則，orderId 模 32 = 庫，orderId / 32 模 32 = 表
- 擴容的時候，申請增加更多的資料庫伺服器，裝好 mysql，呈倍數擴容，4 台伺服器，擴到 8 台伺服器，再到 16 台伺服器。
- 由 dba 負責将原先資料庫伺服器的庫，遷移到新的資料庫伺服器上去，庫遷移是有一些便捷的工具的。
- 我們這邊就是修改一下配置，調整遷移的庫所在資料庫伺服器的位址。
- 重新釋出系統，上線，原先的路由規則變都不用變，直接可以基于 n 倍的資料庫伺服器的資源，繼續進行線上系統的提供服務。