【干货】分库分表最佳实践
何时分库分表
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数据对账，将差异补平。
阶段三
- 老模型不再同步写入，异步补齐（同步数据终态）。
- 此阶段只有离线数据依然依赖老的模型，并且下游的依赖非常多，待改造完就可以完全废除老模型了。
