分片键与路由

分库分表项目里，分片键是第一个「决定对就轻松三年、决定错就返工三年」的选择。我们在这件事上栽过最大的跟头：最早按用户 ID 哈希分片，上线两个月后发现客服查单、商家查单全部带的是订单号，每次都要扫 16 个分片。最后不得不改成订单号分片，期间数据重分布、双写迁移、缓存失效一起上阵，折腾了整整一个季度。

本篇把分片键选择、路由算法、分片规模与路由缓存四件事讲透。核心原则只有一句：分片键应当覆盖最高频的查询条件，而不是看起来最「自然」的字段。

章节 内容 你将获得
2.1 分片键选择 订单号还是用户 ID 分片键的评估方法与反面案例
2.2 路由算法 哈希取模与一致性哈希 算法对比与迁移成本
2.3 分片规则 多少片合适 估算法与一次到位原则
2.4 路由缓存 Redis 加速定位 二级路由与失效方案

分片键的思路在其他系统里同样适用：Java 实战：订单系统 里的订单分区、Go 实战：IM 系统 里的连接分片，本质上都在做同一件事——把「经常一起访问的数据」放到「同一个物理位置」。

延伸阅读