數據庫做拆分的幾種方式：
1．按功能划分（垂直切分）
將不同功能相關的表放到不同的數據庫中，這樣做的好處是非常直觀。但當某一部分的功能其數據量或性能要求超出了可控的范圍，就需要繼續對其進行深入的再切分。
2．按表中某一字段值的范圍划分（水平切分）
當伴隨着某一個表的數據量越來越大，以至於不能承受的時候，就需要對它進行進一步的切分。一種選擇是根據key 的范圍來做切分，譬如ID 為 1-10000的放到A上，ID 為10000~20000的放到B。這樣的擴展就是可預見的。另一種是根據某一字段值來划分，譬如根據用戶名的首字母，如果是A-D，就屬於A，E-H就屬於B。這樣做也存在不均衡性，當某個范圍超出了單點所能承受的范圍就需要繼續切分。還有按日期切分等等。
優點：單表大小可控，天然水平擴展
缺點：無法解決集中寫入瓶頸的問題
3．基於hash的切分
一般采用mod來切分，一開始確定切分數據庫的個數，通過hash取模來決定使用哪台。這種方法能夠平均地來分配數據，但是伴隨着數據量的增大，需要進行擴展的時候，這種方式無法做到在線擴容。每增加節點的時候，就需要對hash 算法重新運算。
所以采用這種方法推薦采用mod 2^n這種一致性哈希
以點評統一訂單庫為例，分庫分表的方案是32*32的，即通過userId后四位mod 32分到32個庫中，同時再將userId后四位div 32 mod 32將每個庫分為32個表，共計分為1024張表。其線上部署情況為8個集群(主從)，每個集群4個庫
4．基於路由表的切分
前面的幾種方式都是根據應用的數據來決定操作的，基於路由表的切分是一種更加松散的方法。它單獨維護一張路由表，根據用戶的某一屬性來查找路由表決定使用哪個數據庫，這種方式是一種更加通用的方案
優點：id和庫的mapping算法可以隨意更改
缺點：可能引入額外的單點