标准答案
- 优先选择高频访问中天然存在的路由维度，例如 tenant_id、user_id 或业务主体 ID，而不是只看字段基数。
- 评估数据量和写入是否均匀，明星用户、头部商家、热点商品或时间递增键都可能造成单分片过热。
- 主要关联对象应尽量共置，例如订单与用户、订单明细与订单，减少跨分片事务和 JOIN。
- 预留扩容策略，如一致性 Hash、虚拟分片、路由表或可迁移的分片范围，避免固定模数无法平滑扩容。
- 所有查询都要能明确路由；无法带分片键的后台搜索、报表和运营查询应走专门索引或异步数据平台。
题目解析
分片键的本质是把业务访问模式固化成物理布局。选错后最痛苦的不是写入本身，而是每个常用查询都要广播到所有节点，随着节点数增长，尾延迟和故障概率同步增加。
热点不是只靠哈希就能解决。哈希可均衡数据，却可能打散需要事务处理的同一业务实体；热点商品秒杀还需要队列、缓存、限流与业务规则配合。
常见误区
- 选一个看似高基数但查询从不携带的字段做分片键，导致几乎所有请求广播。
- 用固定取模分片却没有虚拟节点或迁移方案，新增节点时需要全量搬迁。