哈希索引本质是通过哈希函数将键值映射为无序的槽位地址，彻底丢失原始值大小关系，因此仅支持等值查询（如=、$eq、$in精确值），不支持$gt、$lt等范围查询。
哈希索引本质是“打乱顺序”的映射
哈希索引不支持 $gt、$lt、$gte、$in（含范围语义）、BETWEEN 等查询，根本原因在于它的底层机制：它把原始键值（比如 "2025-01-01" 或 100）喂给哈希函数，输出一个看似随机的整数（如 142857），再把这个整数作为内存或磁盘上的槽位地址去存数据。这个过程彻底丢失了原始值的大小关系——99 和 100 的哈希值可能分别是 3021 和 987654，毫无相邻性可言。
所以当你执行 {age: {$gt: 25}} 时，MongoDB 无法通过遍历“相邻哈希槽”来找到所有匹配文档，因为满足条件的 age 值在哈希空间里是完全离散、无序分布的。
MongoDB 中 createIndex({x: "hashed"}) 只响应等值查询
你显式创建哈希索引后，只有以下写法能命中索引：
db.users.find({x: 123})db.users.find({x: {$eq: 123}})-
db.users.find({x: {$in: [123, 456, 789]}})（注意：这是多个精确值，不是范围）
以下全部**无法使用哈希索引**，会触发 collection scan 或 fallback 到其他可用索引（如果存在）：
db.users.find({x: {$gt: 100}})db.users.find({x: {$ne: 123}})db.users.find({x: {$exists: true}})-
db.users.find({x: /abc/})（正则）
用 explain("executionStats") 查看执行计划时，如果 stage 是 COLLSCAN 或 IXSCAN 但 indexName 不是你期望的哈希索引名，基本就是没用上。
哈希索引和范围分片键选型直接冲突
如果你正在设计分片集群，sh.shardCollection("db.coll", {shardKey: "hashed"}) 创建的是哈希分片键，它只适合高并发等值路由（如按 user_id 查询单个用户）。但一旦业务出现这类需求：
- 查某公司下所有
created_at在最近 7 天的订单 - 按
score排名取 Top 100 - 分页查询
{status: "active", updated_at: {$gt: ISODate("...")}}
就必须放弃哈希分片键，改用范围分片（如 {created_at: 1}）或复合键（如 {company_id: 1, created_at: -1}）。否则这些查询会在所有分片上广播执行，性能断崖式下跌。
替代方案不是“不用索引”，而是换结构
需要范围查询？别硬套哈希索引。B-tree 索引（MongoDB 默认）天然支持：
- 范围扫描（
$gt/$lt） - 前缀匹配（
{a: 1, b: 1}支持{a: 5}或{a: 5, b: 10}） - 排序（
.sort({x: 1})直接利用索引顺序） - 部分字段覆盖（
projection+covered query）
哈希索引唯一不可替代的场景，是解决分片键倾斜问题（比如大量文档 company_id: "abc" 导致某分片过热），此时用 {company_id: "hashed"} 能把流量打散——但它本身不解决查询能力问题，只是让数据分布更均匀。
真正容易被忽略的一点：哈希索引不能“叠加增强”范围能力。哪怕你同时建了 {x: "hashed"} 和 {x: 1}，MongoDB 也只会选一个；而哈希索引在范围场景下永远是无效选项。
