mongodb写入热点本质是分片键设计不当导致新文档持续路由至同一分片；哈希分片通过对分片键值哈希运算打散写入压力，但牺牲$gt/$lt等范围查询能力，且不解决读热点问题。
写入热点本质是分片键路由失衡
MongoDB分片集群的写入热点，根本原因不是硬件或配置问题，而是新文档被持续路由到同一个分片——这几乎总是分片键设计不当导致的。比如用 timestamp 或 ObjectId 作分片键时，值单调递增，哈希前缀或范围划分天然让新数据不断落到末尾 chunk 所在分片，形成“写入雪崩”。sh.status() 看起来 chunk 数量均匀，但实际写请求全压在最新 chunk 对应的那个分片上。
哈希分片键如何打散写入压力
哈希分片不改变数据逻辑顺序，只对分片键值做哈希运算（如 SHA-1），再按哈希结果分配 chunk。这意味着相邻的 event_id: 1001 和 event_id: 1002 会被映射到完全不同的分片上。
- 启用方式：执行
sh.shardCollection("logs", { "event_id": "hashed" }) - 哈希只作用于分片键字段本身，和是否建了
{ event_id: "hashed" }类型的索引无关 - 它不解决读热点——如果查询仍集中在某几个
event_id上，且没建对应索引，该分片 CPU/IO 仍可能飙升
哈希分片后哪些操作会失效或变慢
哈希换来的是写入离散，代价是丧失基于该字段的范围能力。这不是 bug，是设计取舍。
- 所有
$gt/$lt/$gte/$lte查询必须广播到全部分片，响应时间取决于最慢分片 -
$min/$max聚合、.sort({ event_id: 1 })无法利用分片键排序优势，需合并全部分片结果 - 分片键一旦设定就不可修改；想换，只能导出重建集合，停服时间取决于数据量
- 若原始键基数极低（如只有
"pending"/"done"两个值），哈希后仍大概率碰撞在同一分片
真正容易被忽略的负载盲区
很多人只盯着 sh.status() 的 chunk 分布和 config server 的迁移日志，却忘了真实负载由查询模式决定。一个分片 chunk 数量少，但承担了 80% 的聚合查询、全文检索或未命中索引的 find()，它照样是热点。必须结合 db.currentOp({ secs_running: { $gt: 2 } }) 和 mongostat --host mongos:27017 观察实时操作分布，而不是只看元数据是否“看起来均衡”。
