分片键选错会导致查询变广播、写入热点、块迁移卡死；必须匹配高频查询字段，满足高基数、前缀匹配、避免单调递增，并需预判未来12–18个月数据分布与查询路径。
分片键选错，集群性能会断崖式下跌——不是慢一点，而是查询变广播、写入热点、块迁移卡死。它不是“设了就能用”的配置项，而是业务读写模式在数据分布层面的映射。
分片键必须匹配高频查询的过滤条件
mongos 路由依赖分片键值做精准定位。如果常用查询不带分片键，比如 db.orders.find({status: "paid"})，就会变成 scatter/gather，查所有分片再合并，延迟翻倍、CPU 拉满。
- 确认你 80% 以上的读请求是否都包含某个字段（如
user_id、tenant_id、device_id） - 这个字段不能是低基数的（比如
status只有 3–5 个取值），否则块无法均匀分裂，出现单分片扛全部流量 - 避免用时间戳类字段单独作分片键（如
create_time），写入会集中到最新块，形成热点
复合分片键要严格遵循查询前缀匹配
MongoDB 的复合分片键（如 {"tenant_id": 1, "user_id": 1}）只对含前缀的查询生效。没 tenant_id 就等于没分片键。
-
db.orders.find({tenant_id: "t123"})✅ 路由到确定分片 -
db.orders.find({tenant_id: "t123", user_id: "u456"})✅ 精准定位 -
db.orders.find({user_id: "u456"})❌ 广播到所有分片 -
db.orders.find({tenant_id: "t123", status: "paid"})✅ 仍能路由，但status不参与分片，只用于分片内过滤
如果你的租户隔离是刚性要求（SaaS 场景），tenant_id 必须放在复合键最左；如果是用户级服务，user_id 就是天然前缀。
写入热点和块分裂必须提前验证
分片键值分布决定块能否自动均衡。如果键值单调递增（如 ObjectId、自增 ID、毫秒时间戳），新文档永远写入最后一个块，该块持续分裂、迁移，balancer 始终追不上。
- 用
sh.status()观察各分片的 chunk 数量是否严重倾斜（比如一个分片 200+ chunk，其他只有 20） - 插入测试数据时，用
ObjectId().getTimestamp()或哈希函数打散（如{"hash": md5(user_id), "user_id": 1}），但注意哈希后丧失范围查询能力 - 生产环境上线前，至少用真实流量比例压测 24 小时，重点看
chunks迁移日志和moveChunk错误
一旦设错就无法修改，只能重建集合
sh.shardCollection() 执行后，分片键不可变更。想换？得导出全量数据 → 创建新分片集合 → 重新 shardCollection → 导入 → 切流量。停机或双写窗口不可避免。
真正容易被忽略的，是业务增长带来的键分布漂移：今天 user_id 均匀分布，半年后某大客户导入百万账号，ID 段集中，块立刻失衡。所以分片键设计不是上线前填个字段，而是要预判未来 12–18 个月的数据生成逻辑和查询路径。
