分库分表数据落地方案-创新互联

将单个数据库拆分，单个表拆分为多个表；根据指定字段值或者值的部分计算数据库索引和表索引；

一个典型的数据分布（示例为一库多表，选择一库单表还是一库多表按业务实际情况）：

这里按 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 值或值的部分来计算分库、分表索引；