将单个数据库拆分，单个表拆分为多个表；根据指定字段值或者值的部分计算数据库索引和表索引；
一个典型的数据分布（示例为一库多表，选择一库单表还是一库多表按业务实际情况）：
这里按 2 库2 表举例，装填临界:4；
计算分库索引公式：
一. 自然递增id：
适合同类别仓储管理类业务场景（即货物区分类别相同，如同一工厂生产的一种啤酒，来什么货物存什么货物）；
1. 当分库表字段值 {fieldValue} 大于等于4时，需要先对4取余，跳转 2.，小于4时 跳转 2.；
2. db_index = {fieldValue} / db_indices_count；
3. table_index = {fieldValue} % [一个物理库内分表总数]；
二. 预先分配库表索引编号：
用户注册时就按照用户的地区、性别、年龄、选择的产品类型等信息决策出用户的分库、分表索引值（决策逻辑公式应该要满足足够的分布性）；
1. 直接按照用户的分库分表属性值路由分库、分表；
分库分表数据装填概况（依次插入id 1~16的数据分布情况）：
id值
db_0 : {
user_0 4 8 12 16
user_1 1 5 9 13
}
db_1: {
user_0 2 6 10 14
user_1 3 7 11 15
}
找到分库、分表索引后，再根据SQL的Command Type （如SELECT、UPDATE） 或者用户强制指定情况来决定是走 master/slave Leader / Follower （政治正确统称）库，
如果主、从有多个物理实例，则需要按照一定的规则（随机或者RoundRobin之类）来挑选一个物理节点（host / port）连接；
其中：
1. 修改新增update、insert 必须使用主节点连接；
2. 查询则需要判断区分 普通 SELECT 还是 SELECT FOR UPDATE / SELET IN SHARE MODE 事务操作，普通SELECT在容忍主从延迟的业务场景下可以到从执行，其他到主执行；
3. 一个SQL执行完毕之后可能要清除路由上下文；
4. 大多数web2.0 业务场景（如抖音用户信息页）都需要按照user_id 值或值的部分来计算分库、分表索引；