昨天我們分享了怎麼不停機進行分庫分表數據遷移（數據庫分庫分表，生產環境不停機數據遷移）後來有好多朋友問我，說他們的系統雖然也到了差不多分表的地步了，但是，不知道具體拆分多少張表，分多了又怕浪費公司資源，分少了又怕後面怎麼去擴容，還有另一些朋友說，所在的公司規模還不大，尚在發展中，公司壓根就沒這麼資源給他們這麼去拆分。

這些朋友的問題提的很好，因爲真正的結合自己公司的業務去思考了。所以，我今天就來幫助解答下，並且幫着更多有類似困擾的朋友進行統一的講解，教大家該怎麼去做，掌握這套思想之後，其實你們就能舉一反三了，我相信，今天學完之後，你們就可以解開自己的心中疑惑了。

好，那我們就來進入正題。其實上面提到的那些問題，就是歸類到一個問題上，那到底是什麼呢？就是我們分庫分表怎麼去動態擴容的問題。你現在想想看是不是，你開始不知道分多少庫表，在分多或者分少只中進行糾結，還擔心自己的資源不夠等等，這些都是因爲不知道怎麼去動態擴容。下面我們就來看看，我們的數據庫分庫分表，該怎麼去動態擴容。

笨方法擴容（強烈不推薦）

既然是強烈不推薦的笨方法，我爲什麼還要說呢？因爲這種方法的確有部分人這麼幹，簡單粗暴還累人。那究竟是什麼樣的累人方式呢，我想大家應該猜得到的，和前面停機數據遷移類似，但是這個比首次停機遷移要複雜得多。

比如，開始分庫分表的時候，是這樣想的，由於想着我們公司資源有限，或者是不知道該分多少，就先隨便分幾個試試，所以我們現在就將原單庫表分了 2 個庫每個庫分 4 張表類似這樣的。誰知道，咱們公司業務發展速度驚人，我們之前分的2 * 8的庫表完全不滿足現在的業務需求。

這個時候，就有人這麼幹了，沒事啊，我們就像我們之前那樣嘛，不管是停機的還是在線的，同樣寫一個後臺數據遷移程序，將現在的這些庫表全查出來，然後我們用新的hash策略進行路由到我們新的這些庫表不就行了，比如以前是對2 和4 進行哈希的，現在改成了 4和8進行哈希庫表了。如果分庫分表策略忘了的可以回去看看（數據庫分庫分表方案，優化大量併發寫入所帶來的性能問題），真的有這麼幹的。

我不知道你們會不會想到這麼幹，但是我的確見過這麼幹的，包括我們自己公司有些小組也有這麼想的，但是我現在可以告訴你，就此打斷這個念頭了，爲什麼不建議你們這麼做呢？

首先顯得你自己非常的不專業，更是喫力不討好的活。
本來我們開始單庫表數據分庫分表的時候，數據就巨多了，至少得千萬級別的吧，我們是到了億的時候採取分的，你想想看，你分了2*4的庫表之後，現在還想用之前的流程再來，那數據可不是一個量級的，幾十億的數據很正常，你如果這樣的去查出來，再去重新hash入庫在校驗。這麼一來，你幾個小時能搞定嗎？顯然不能的啊。
萬一要是出錯了，還得重新回滾再來，那時你就會特別懊惱吧，懊惱之後就更會出錯。所以，這裏我強烈不推薦你這麼幹，因爲真的很不靠譜還累了你自己，活還不一定能出來。

分庫分表動態擴容

上面我和大家提到了不能直接通過寫程序工具來再次查詢數據來進行擴容，也說了爲什麼不推薦那麼做，只是想讓大家現在看到了就儘量去避免踩坑。下面我們就來看看比較靠譜的擴容方法，也就是動態擴容，那我們該怎麼使用這種方案呢？

核心思想

在分庫分表策略那篇文章，我就建議，如果不用分庫分表我們堅決不去分庫分表。如果是到了分庫分表的地步了，我們最好就是一次性分到位，比如分個32 * 32的這樣的規模，目的就是防止出現擴容的複雜性，所以，今天這個問題也就引出來了。

這個時候，你們可能還是會說，我們公司就是資源有限了，你還讓我一次性分到位，公司沒那麼多機器給我做這些數據庫分庫分表。的確，這個問題是有，因爲大家所身處的公司，並不是都是行業數一數二，資源充分。但是沒關係啊，不影響我們做架構，是什麼意思呢？

我的意思是說，我在做分庫分表架構時，不一定非得一開始就要將一個數據庫服務器放一個MySql數據庫啊，我可以在一個數據庫服務器上放多個MySQL實例啊，對吧。比如，現在我一次性分32個庫每個庫32張表。你就給我 4 臺數據庫服務器，然後我每一臺部署 8 個MySQL數據庫實例，這樣子的來弄，並不非得要求一個數據庫一臺服務器。最次的話，如果你公司真的摳的話，可以只給我一臺好的配置的，我把32個數據庫都放在一臺服務器總行吧，當然這麼摳的畢竟少數哈。

如何動態擴容

在我們數據庫分庫分表動態擴容的時候，我們要搞清楚目前造成我們急需擴容的原因是什麼？是什麼原因直接會觸發我們擴容，也就是我們要擴容的動機。一般有兩個原因會直接觸發我們的擴容。

數據庫併發瓶頸，也就是當前你給我的那四臺機器啊，隨着業務的猛增，相關請求併發已經超過了我們現在數據庫服務器的併發範圍

和以前一樣，現在分的庫表數據已經快滿了，當前數據庫表裝不下了，又到了上億的數據，服務器磁盤容量也不夠存儲了，這個時候我們就需要對其進行擴容

首次分庫分表時，我一次性分爲32 * 32這樣的，即分成32個庫，然後每個庫 32 張表。
現在你就給我 4 臺數據庫服務器，那我就在每臺數據庫服務器上搭建 8 個MySQL數據庫實例，每個庫32張表。
現在隨着公司業務的發展，我們的四臺數據庫服務器達到了併發或者磁盤瓶頸，我們這個時候我們又要對其進行拆分，當然這裏就是直接動態擴容了，不需要在單獨拆分了。比如，我們根據目前業務增長的勢頭分析，再將其擴容四臺機器出來（公司業務這麼好，如果你還說沒資源，那就說不過去了吧），將之前的每臺數據庫服務器上數據庫分一半出來到新的數據庫服務器上來，即現在一共有 8 個數據庫服務器，然後每臺服務器分 4 個數據庫，每個數據 32 張表。
如果業務繼續上升，又需要擴容，這個時候還是可以按照上面邏輯來動態擴容，在不用動業務代碼的情況下，我們可以擴到 32 臺數據庫服務器，每臺放一個數據庫。這種的規模一般可以支撐你好多好多年的業務了。