将不同功能相关的表放到不同的数据库中，这样做的好处是非常直观。但当某一部分的功能其数据量或性能要求超出了可控的范围，就需要继续对其进行深入的再切分。

当伴随着某一个表的数据量越来越大，以至于不能承受的时候，就需要对它进行进一步的切分。一种选择是根据key 的范围来做切分，譬如ID 为 1-10000的放到A上，ID 为10000~20000的放到B。这样的扩展就是可预见的。另一种是根据某一字段值来划分，譬如根据用户名的首字母，如果是A-D，就属于A，E-H就属于B。这样做也存在不均衡性，当某个范围超出了单点所能承受的范围就需要继续切分。还有按日期切分等等。

优点：单表大小可控，天然水平扩展

缺点：无法解决集中写入瓶颈的问题

一般采用mod来切分，一开始确定切分数据库的个数，通过hash取模来决定使用哪台。这种方法能够平均地来分配数据，但是伴随着数据量的增大，需要进行扩展的时候，这种方式无法做到在线扩容。每增加节点的时候，就需要对hash 算法重新运算。

所以采用这种方法推荐采用mod 2^n这种一致性哈希

以点评统一订单库为例，分库分表的方案是32*32的，即通过userId后四位mod 32分到32个库中，同时再将userId后四位div 32 mod 32将每个库分为32个表，共计分为1024张表。其线上部署情况为8个集群(主从)，每个集群4个库

前面的几种方式都是根据应用的数据来决定操作的，基于路由表的切分是一种更加松散的方法。它单独维护一张路由表，根据用户的某一属性来查找路由表决定使用哪个数据库，这种方式是一种更加通用的方案

优点：id和库的mapping算法可以随意更改

缺点：可能引入额外的单点