Hashed分片键导致范围查询变慢，因其哈希值打乱原始顺序，使范围查询需广播至所有分片执行分散-聚集操作；等值查询才可精准路由。
Hashed分片键为什么会导致范围查询变慢？
因为哈希后的值完全打乱了原始字段的顺序。比如 order_id: 1001、1002、1003 经过哈希后，可能分别落到分片 s1、s3、s2，彼此毫无规律。一旦你执行 { order_id: { $gte: 1001, $lte: 1005 } } 这类范围查询，MongoDB 就必须把请求发给**所有分片**，再把结果汇总——这就是“分散-聚集查询”，I/O 和网络开销陡增。
常见错误现象：explain("executionStats") 显示 nReturned 很小但 totalDocsExamined 或 executionTimeMillis 异常高；监控里看到多个分片同时出现读负载尖峰。
- 只有等值查询（
{ order_id: 1001 }）能精准路由到单个分片，性能才接近最优 - 如果业务中 70% 以上的查询是范围型或前缀型（如
user_id按注册时间范围查），别硬上 Hashed 分片键 - 想保留范围能力又需均匀分布？考虑复合分片键，例如
{ region: 1, order_id: "hashed" }，用高基数字段做前缀来“锚定”一部分路由
浮点数用 hashed 索引会出什么问题？
MongoDB 对浮点数做哈希前，会先截断为 64 位整数——2.3、2.9、2.999999999 全部变成 2，再哈希。结果就是多个逻辑上不同的值被塞进同一个哈希桶，发生**确定性哈希冲突**，不仅查不准，还可能漏数据。
典型错误场景：用 price: { $type: "double" } 字段建 hashed 索引，然后执行 { price: 2.3 } 查询，却匹配到 2.2 或 2.8 的文档。
- 绝对不要对浮点字段直接建
hashed索引；如需分片，改用精确值（如 cents 整数）、字符串化后哈希，或换用范围分片 - 检查已有索引：运行
db.collection.getIndexes()，确认key字段里没有{ "price": "hashed" }这类配置 - 若已上线且无法改 schema，至少在应用层加校验：读取后二次过滤原始浮点值，避免脏数据透出
为什么 hashed 分片键还是会出现“热分片”？
哈希本身只解决“写入倾斜”，不解决“访问倾斜”。即使数据均匀散落在各分片，只要业务请求集中在某类哈希值附近（比如大量查 user_id: "u123" 对应的哈希桶，而该桶恰好落在 s2），s2 就会成为瓶颈——这不是哈希函数的问题，而是访问模式和分片键选择没对齐。
容易被忽略的细节：哈希是确定性的，但“热点”可能来自低基数字段（如 status: "active"）+ 高频查询组合，导致某几个哈希值被反复访问。
- 用
sh.status()观察各分片的chunks数量是否均衡，再结合mongostat看netIn/netOut是否某分片持续偏高 - 如果发现某分片长期 CPU/IO 偏高，但 chunk 分布正常，大概率是查询热点而非数据倾斜
- 缓解方法不是换哈希函数，而是加一层缓存（如 Redis）或调整查询方式（比如用
_id替代业务字段查详情）
如何验证你的 hashed 分片键是否真均匀？
不能只看 chunk 数量，得看实际数据分布。MongoDB 的哈希函数（Murmur3）本身质量很高，问题往往出在分片键字段本身的基数不足或存在大量重复值。
一个真实踩坑案例：用 { country_code: "hashed" } 分片，但全球只有 200 多个国家，哈希后最多也就 200 多个不同桶，远低于分片数，结果大量 chunk 聚在少数分片上。
- 快速检查基数：运行
db.collection.aggregate([ { $group: { _id: "$country_code", count: { $sum: 1 } } }, { $sort: { count: -1 } } ])，看高频值占比 - 真正有效的验证方式：抽样 10 万条记录，计算
db.collection.distinct("_id").length和db.collection.distinct("country_code").length，比值低于 0.1 就危险 - 补救不一定要重分片——可尝试升级为复合键，例如
{ country_code: 1, user_id: "hashed" }，用高基数字段“撑开”分布空间
哈希冲突在分片场景下从来不是“能不能避免”的问题，而是“在哪暴露、由谁承担代价”的问题。MongoDB 不报错，但慢查询、热分片、查不准这些症状，全是它在悄悄说话。
