适用场景

分库分表是"最后手段"：先优化索引与 SQL、再加缓存与只读实例，最后才考虑拆分。因为拆分之后，跨库查询与事务都会成为长期成本。

配置步骤（拆分方案设计）

# 1) 现状分析：单表行数、QPS、TPS、磁盘占用
# 2) 拆分维度：按用户 ID 哈希（8 库 64 表）
# 3) 分片键与路由规则文档化
# 4) 全局 ID 方案：号段模式（DB 申请区间）
# 5) 迁移方案：双写 + 数据校验

关键参数与建议

  • 拆分时机：单表数据量、写入压力、单机容量达到瓶颈
  • 拆分维度：按业务（订单/用户）、按时间（月份）、按哈希（用户 ID）
  • 分片键选择：高频查询条件优先，避免跨分片查询
  • 全局唯一 ID：雪花算法或号段模式
  • 跨分片查询：尽量在应用层聚合，避免中间件复杂 JOIN

容易踩的坑

  • 按时间分表却按 ID 查，跨表查询频繁
  • 分片数拍脑袋定，后期扩容困难
  • 无全局 ID 方案，主键冲突

验证与巡检

# 验证：按路由规则抽样验证数据分布是否均匀
  • 巡检：分片分布均匀、路由规则文档化

小结

分库分表的验收：写入压力分摊、热点分片可控、跨分片查询有明确方案与性能数据。没有数据的拆分是拍脑袋。

> 说明：文中命令为通用写法，不同型号/版本可能略有差异，落地前请对照设备实际版本的官方文档；带外管理与安全设备变更建议先在测试设备验证。