分片键更新不均衡的根本原因是更新操作完全由当前分片键值决定，低基数字段（如status只有两个值）导致更新始终集中在少数chunk或shard上形成热点；哈希分片可有效打散更新压力，但要求字段基数足够高，且不能对低基数字段哈希或在复合键中混用hashed；复合键必须确保前导字段高基数，否则chunk总数被锁死，任何分片策略均失效；更新分片键字段会触发高开销迁移，应禁止应用层直接更新。
分片键更新不均衡的根本原因
更新操作落到哪个分片，完全由文档当前的分片键值决定。如果大量更新集中在少数几个键值上（比如 status 字段只有 "pending"/"done" 两个值），那不管写入多频繁，这些更新永远只打在同一个 chunk、甚至同一个 shard 上——这就是“更新热点”。它和写入热点本质一致，但容易被忽略，因为大家更关注插入时的分布。
哈希分片是更新均衡最直接的解法
哈希分片强制把相同原始值映射到不同物理位置，天然打散更新压力。只要原始字段基数够高，更新就会均匀落到各 shard。
-
sh.shardCollection("db.coll", {"user_id": "hashed"})比{"user_id": 1}更适合高频更新用户资料的场景 - 避免对低基数字段哈希，比如
{"region": "hashed"}（全球就几十个 region），哈希后仍只有几十个有效取值，chunk 数上限被锁死 - 哈希后无法做范围查询，如果业务有
user_id > 100000这类需求，得额外建索引或接受广播查询代价
复合分片键要警惕“前导字段低频”陷阱
复合键如 {"tenant_id": 1, "created_at": 1} 看似合理，但如果 tenant_id 只有 5 个活跃租户，那整个集合最多只能分裂出 5 个 chunk——后续所有更新都挤在这 5 个 chunk 里，平衡器根本无从搬移。
- 必须确保第一个字段（前导字段）具备足够高基数，否则后续字段再怎么变化也无效
- 如果业务强依赖时间范围查询，又想分散更新，可改用
{"tenant_id": "hashed", "created_at": 1}，让 tenant 分布打散，同时保留时间局部性 - 注意：
"hashed"只能用于单字段，复合键中不能写{"tenant_id": "hashed", "created_at": 1}—— 这语法非法，MongoDB 会报错Cannot use hashed index on compound key
更新分片键字段本身要格外小心
MongoDB 允许更新分片键字段值（除非是 _id），但这会触发文档迁移——mongos 要先删旧位置、再插新位置，开销远大于普通更新。一次批量更新可能引发数百次跨分片移动，直接拖垮平衡器。
- 生产环境应禁止应用层更新分片键字段；如确需变更，走
sh.splitAt()+sh.moveChunk()手动预拆+搬迁，避开自动平衡窗口 - 使用
db.collection.findOneAndUpdate()时务必确认 filter 条件含分片键，否则变成全集群广播更新，延迟飙升 - 监控
moveChunk日志和chunk migration rate，一旦发现迁移量突增，立刻查是否有人在改分片键字段
sh.shardCollection() 那一行就定死了。真正容易被忽略的是：**复合键的前导字段基数不足时，哈希、范围、任何策略都失效**——因为 chunk 总数被锁死，再怎么搬也搬不出新空间。 
