【干货】分库分表最佳实践 - 有梦想的老王 - 博客园

何时分库分表

MySQL单表（innoDB）可以存储10亿级数据，只是这时候性能比较差，业界公认MySQL单表容量在1KW以下是最佳状态，因为这时它的BTREE索引树高在3~5之间。

参考阿里开发手册建议：

1.单表行数超过 500 万行或者单表容量超过 2GB，才推荐进行分库分表；如果预计三年后的数据量根本达不到这个级别，请不要在创建表时就分库分表。

2.实际情况受mysql机器配置等多方面影响，可能数据量很大但性能依旧不错，但考虑后续发展一定要进行分库分表考虑。

如何分库分表

设置合适的分片数量

根据实际的业务场景选择合适的分片数据，参考如下：

• 满足当前数据平均后的数据量在一个合理的范围（<=100w）
• 预估未来5年的数据量发展情况，数据量在一个合理的范围（500w左右，有合理的归档备份机制）

选择合适的分片字段

根据实际的业务场景选择适当的分片字段，要达到如下要求：

• 字段类型常规
• 字段不易过多
• 字段应该是业务场景大多数都会被使用的

设计合理的分片规则

分表数量和分表字段确定后，要设计一个合理的分表规则，良好的分表规则要达到如下条件：

• 规则计算高效，逻辑清晰
• 规则计算后，分片数据均匀
• 方便后续扩容分片

如何保证分片数据均匀，参考：

• 分片字段本身就是随机均匀的，可以直接使用
• 分片字段随机，但不均匀，如对总分片取模后，会导致数据不均匀，建议先对分片字段进行2次随机处理（如：zebra提供的：md5/crc32 方法）

如何保证方便后续分片扩容，参考：

• 如果是按照时间或数值范围进行分片，只需要创建分片库表，修改分片规则，立即生效
• 如果是hash分片，条件允许可考虑停服迁移，停止服务，将数据按新分片规则进行迁移，修改分片规则，启动服务
• 某些情况下可考虑升级从库，如2分库扩容为4分库，可将从库升级为主库并修改分片规则，后续可将冗余的数据进行清除并补上缺失的从库。
• 数据库双写，同时按新老分片规则写入两套物理表，并逐渐下线老数据模型，可参考-新老迁移参考

SQL使用注意

如何高效的使用分库分表，核心是做到尽量的路由到最少的表，最好是只路由到一个表里面

核心规则如下：

• 能带分片字段的就尽量把其带上
• 尽量不使用范围查询
• 无分片使用limit时不要查询太靠后的数据
• 尽量不要使用复杂的sql
• sql写法尽量规范

新老迁移方案参考

阶段一

• 数据库双写（事务成功以老模型为准），查询走老模型。
• 每日job数据对账，并将差异补平。
• 通过job导历史数据。

阶段二

• 历史数据导入完毕并且数据对账无误。
• 依然是数据库双写，但是事务成功与否以新模型为准，在线查询切新模型。
• 每日job数据对账，将差异补平。

阶段三

• 老模型不再同步写入，异步补齐（同步数据终态）。
• 此阶段只有离线数据依然依赖老的模型，并且下游的依赖非常多，待改造完就可以完全废除老模型了。