直接回答：分片键的选择标准：出现在绝大多数高频查询的 WHERE 里（避免广播）、分布均匀（避免热点）、基数足够（用户 ID、订单 ID 天然合适；状态枚举不行）。常见策略：哈希取模（均匀但扩容要迁移）、范围分片（好扩容但易热点，适合时间序列）、一致性哈希（迁移量小）。分片键选定即定终身，后期更换等于数据重分布，前期压测和容量推演要做足。

展开解析：分片后的问题清单与解法。跨片查询：能广播聚合的（COUNT 类）由中间件合并；不能的（多维度检索）异构到 ES/数仓，数据库只服务分片键路径。全局唯一 ID：雪花/号段。跨片事务：尽量避免——业务设计上让事务内聚到单分片（订单与其明细同片），避免不了用最终一致（本地消息表/Saga），分布式事务（XA）性能和可用性代价慎用。关联表：跟随主表分片（相同分片键）或做全局冗余小表（字典类）。扩容：从 N 到 2N 的翻倍迁移配合双写过渡，或一开始用足够大的逻辑分片数（如 1024 逻辑槽映射到物理库），扩容只挪槽。中间件选型（ShardingSphere、Vitess、或云原生分布式库）本质是把这些复杂度交给谁的问题。

追问方向：为什么分布式数据库（TiDB/Spanner）在蚕食手工分片场景？基因法分片键如何解决多维度查询？迁移期一致性怎么校验？

（约 480 字）