之前的幾篇關(guān)于分表的，提到的分表策略不夠詳細(xì)，我在這篇中補充一些分表策略吧：

按號段分：

(1) user_id為區(qū)分，1～1000的對應(yīng)table1，1001～2000的對應(yīng)table2，以此類推，或者以id最后兩位數(shù)字為區(qū)分，分到table00-table99表中；

優(yōu)點：可部分遷移

缺點：數(shù)據(jù)分布不均

(2)hash取模分：

對user_id進行hash(或者如果user_id是數(shù)值型的話直接使用user_id 的值也可)，然后用一個特定的數(shù)字，比如應(yīng)用中需要將一個表切分成4個表的話，我們就用4這個數(shù)字對user_id的hash值進行取模運算，也就是user_id%4,這樣的話每次運算就有四種可能：結(jié)果為1的時候?qū)?yīng)table1；結(jié)果為2的時候?qū)?yīng)table2；結(jié)果為3的時候?qū)?yīng)table3；結(jié)果為0的時 候?qū)?yīng)table4，這樣一來就非常均勻的將數(shù)據(jù)分配到4個table中。當(dāng)然還有其他一些算法，可以以user_name作為參數(shù)，進行hash運算，可參考@php hash算法使用

優(yōu)點：數(shù)據(jù)分布均勻

缺點：數(shù)據(jù)遷移的時候麻煩，不能按照機器性能分?jǐn)倲?shù)據(jù)

(3)在認(rèn)證庫中保存數(shù)據(jù)庫配置

就是建立一個table，這個table單獨保存user_id到table的映射關(guān)系，每次訪問數(shù)據(jù)庫的時候都要先查詢一次這個數(shù)據(jù)庫，以得到具體的table信息，然后才能進行我們需要的查詢操作。

優(yōu)點：靈活性強，一對一關(guān)系

缺點：每次查詢之前都要多一次查詢，性能大打折扣

以上就是我們在開發(fā)中通常選擇的方式，在一些復(fù)雜的項目中我們也可以混合使用這幾種方式。

總結(jié)

以上是生活随笔為你收集整理的mysql订单表上亿怎么分表_[转]单表上亿的数据量如何分表的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。