订单或用户事件常用稳定业务键哈希，例如 cityHash64(user_id)，同一用户落同一分片，用户查询可带分片键路由，整体分布也比较均匀。不能用低基数地区，也不能用当前日期简单取模，否则热点会集中到少数分片。

我会回放 Top 查询，看有多少能携带分片键。跨全局聚合本来就要访问所有分片，但高频点查如果每次广播，分片越多延迟和资源越差。必要时为另一查询维度构建独立聚合表，而不是让所有需求共用一张分布式表。

上线前用真实键分布计算每片行数、字节和 QPS，特别模拟超级用户。监控最大/平均负载比、远程读取、最慢分片和写入队列。

扩容后旧数据不会自动按新规则完美重排，需要明确新写路由、历史迁移和查询兼容期。分片键不是只影响今天建表，还决定未来扩容成本。