哈希分片键通过哈希运算打散写入热点，但牺牲范围查询能力；适用于写多读少、分片键高基数且能容忍无范围查询的场景，不适用于需时间窗口聚合或低基数键的情况。
哈希分片键能有效打散写入热点，但不是万能解药——它牺牲范围查询能力换均匀分布，用前必须确认业务是否接受这个 trade-off。
为什么哈希分片键能缓解写入热点
写入热点本质是大量新文档被路由到同一个分片，常见于 timestamp、_id（ObjectId）这类单调递增字段作分片键时。哈希分片通过对键值做哈希运算（如 sh.shardCollection("logs", { "event_id": "hashed" })），让逻辑上相邻的键映射到完全不同的分片上，从而把写压力摊平。
注意：哈希只作用于分片键字段本身，不改变索引结构；它和 hashed 索引类型无关，后者用于单机查询优化。
哈希分片键的实际限制与坑点
启用哈希分片后，以下操作会受限或失效：
- 无法执行基于该字段的范围查询（如
{ event_id: { $gt: 100, $lt: 200 } }），MongoDB 必须广播到所有分片 - 无法使用该字段做
$min/$max聚合，也无法高效做sort() - 分片键一旦设定就不可修改，除非导出重建集合
- 如果原始键基数极低（如只有 3 个取值），哈希后仍可能碰撞集中在少数分片
什么时候该用哈希分片，什么时候不该
适合场景：
- 写多读少，且读请求基本靠
_id或其他带索引的非分片键字段精准定位（如用户行为日志写入 + 按 user_id 查询） - 分片键天然高基数（如 UUID、手机号、邮箱）
- 业务能容忍“无法按时间范围查最近 N 条”的限制
不适合场景：
- 需要高频按时间窗口聚合分析（如“过去一小时错误数”）
- 分片键本身低基数（如
status: ["pending", "done", "failed"]） - 已有集合数据量大、无法停服重建
替代方案比哈希更灵活的边界情况
若业务既要一定范围查询能力，又要防热点，可考虑：
- 复合分片键：例如
{ region: 1, event_id: 1 }，先按地理/租户维度分流，再在局部做均匀写入 - 预分片（pre-splitting）：对已知会高频写入的键区间手动切 chunk，避免初始全落在一个分片
- 应用层加盐：写入前对原始 ID 拼接随机后缀再哈希，提升分散度（需客户端配合）
真正容易被忽略的是：哈希分片后，sh.status() 显示的 chunk 分布可能看起来均匀，但实际 CPU/IO 热点仍可能出现在某一分片——因为查询模式或索引缺失导致该分片承担了更多读负载。必须结合 db.currentOp() 和 mongostat 观察真实负载，而不是只看 chunk 数量。
