當一個應用的數據量大的時候，我們用單表和單庫來存儲會嚴重影響操作速度，如mysql的myisam存儲，我們經過測試，200w以下的時候，mysql的訪問速度都很快，但是如果超過200w以上的數據，他的訪問速度會急劇下降，影響到我們webapp的訪問速度，而且數據量太大的話，如果用單表存儲，就會使得系統相當的不穩定，mysql服務很容易掛掉。所以當數據量超過200w的時候，建議系統工程師還是考慮分表.
以下是幾種常見的分表算法。
1.按自然時間來分表/分庫;
如一個應用的數據在一年後數據量會達到200w左右，那麼我們就可以考慮用一年的數據來做為一個表或者庫來存儲，例如，表名為app，那麼2010年的數據就是app_2010，app_2011;如果數據量在一個月就達到了200w左右，那麼我們就可以用月份來分，app_2010_01，app_2010_02.
2.按數字類型hash分表/分庫;
如果我們要存儲用戶的信息，我們應用的注冊量很大，我們用單表是不能滿足存儲需求的，那麼我們就可以用用戶的編號來進行hash，常見的是用取余操作，如果我們要分30張表來存儲用戶的信息，那麼用戶編號為1的用戶1%30=1，那麼我們就存在user_01表裡，如用戶的編號為500，那麼500%30=20，那麼我們就將此用戶的信息存儲在user_20的表裡.
3.按md5值來分表/分庫;
我們假設要存儲用戶上傳的文件，如果上傳量大的話，也會帶來系統的瓶頸問題，我們做過試驗，在一個文件夾下如果超過200個文件的話，文件的浏覽效率會降低，當然，這個不屬於我們本文討論的范圍，這塊也要做散列操作.我們可以用文件的用戶名來md5或者用文件的md5校驗值來做，我們就可以用md5的前5位來做hash，這樣最多我們就可以得到5^5=3125個表，每次在存儲文件的時候，就可以用文件名的md5值的前5位來確定這個文件該存那張表.
4.實例:某微博的url加密算法和存儲策略的猜想.
現在好多微博都用這樣的url來訪問，如果他們的域名為www.example.com，那麼如果你發微博的時候，你會發現你所發的url都變成了http://t.cn/Mx4ja1，這樣的形式，他們是怎麼進行這樣的轉換呢?我猜想就是用到了我們上面講的md5的存儲和查找規則，用你發的url來進行md5，得到md5值之後，如我們例子來說，就會用前6位來進行分表.
5.分表所帶來的問題.
分表也會帶來一系列的問題，如分頁的實現，統計的實現，如果我們要做一個所有數據的分頁，那麼我們得每張表都得遍歷一遍，這樣訪問效率會很低下.之前我嘗試過用mysql的代理來實現，最終用tcsql來實現了.
6.分表算法的選擇.
如果你的應用數據量不是特別大的話，最好別用分表。
