tbl_account. 表【主鍵ID，使用者名稱，密碼，註冊時間，……】

業務邏輯開發完成，OK。內網測試沒問題，業務流程正常，可以提供服務了。此時資料是A數量級條。

過了幾天自己在該表插入B數量級條測試資料，發現查詢速度（註冊，登入），瞬間變慢了，好難過……
憑藉多年的臨床經驗告訴我，應該進行分表了。
採用將使用者名稱hash的方式，mod N之後把資料hash到N張表（tbl_account000,tbl_account001,tbl_account002,……）中，這時候單張表就會小很多了。
修改完畢，業務流程正常，服務正常。

過了幾天自己用測試資料裝入以上分好的表中，將資料量新增到C數量級。再次發現業務響應變慢了，十分難過……

這次資料量的大小快把資料庫所在伺服器硬碟撐滿了,小夥伴怕不怕呢

如果外網運營真的滿了，呵呵吧
好在我們有一顆不服輸的心

大學時演算法老師說的好，分而治之。
所以我們又有了新的解決辦法。
將所有的業務資料拆分為M個庫，同樣採用hash使用者名稱的方式，將使用者資料hash到不同的庫中（不同的庫位於不同的伺服器主機上），每個庫中同樣採用分表的處理辦法。