$ne 几乎总是绕过索引，因其要求排除某值后返回其余所有，与B-tree索引的有序遍历和范围跳转设计冲突，必须扫描整个索引逐项比对，等效全表扫描。
$ne 几乎总是绕过索引，不是配置问题，是 MongoDB 引擎的底层行为限制。
为什么 $ne 无法利用 B-tree 索引
MongoDB 的 B-tree 索引依赖有序遍历和范围跳转，而 $ne 要求“排除某个值后返回其余所有”，这与索引的设计目标冲突：它无法用一次范围查找跳过目标值，必须逐条检查索引项是否匹配“不等于”条件——等价于扫描整个索引再过滤。即使字段有单字段索引，explain("executionStats") 也会显示 totalDocsExamined 接近集合总文档数，executionStages.stage 可能是 IXSCAN，但实际效率和全表扫描无异。
- 索引中每个键值仍需比对，无法提前终止或跳段
- 选择性越低（如 status 字段只有 "active"/"inactive" 两种值），
$ne: "inactive"就越接近查全部文档 - 复合索引中只要左侧字段用了
$ne，右侧所有字段索引能力立即归零，例如{status: 1, createdAt: -1}上执行{status: {$ne: "deleted"}, createdAt: {$gt: ...}}，createdAt部分完全失效
$ne 和 $nin 在 explain 中的典型表现
运行 db.collection.explain("executionStats").find({field: {$ne: "val"}}) 后重点关注三个字段：
-
totalKeysExamined很高，且接近索引总条目数 → 说明在扫索引 -
totalDocsExamined也极高，甚至等于集合总文档数 → 说明几乎每条都 fetch 了完整文档 -
nReturned却很小 → 大量无效读取，典型的索引“假命中” - 如果
executionStages.stage是COLLSCAN，那连索引都没进；如果是IXSCAN但后面跟着大量FETCH+filter，说明索引只起了极小作用
真正可用的替代方案
硬写 $ne 是放弃索引友好性的开始。生产环境应避免直接使用，转而采用可落地的正向建模：
- 把否定逻辑移到应用层：先
db.collection.find({field: {$in: ["val"]}})拿到要排除的 ID 列表，再内存 diff 剩余数据 - 增加冗余标记字段，比如将
status: {$ne: "deleted"}改为is_deleted: false，然后建{is_deleted: 1}索引 - 若必须支持多值排除，改用白名单
$in查询（它能高效走索引），并确保业务能接受“只查已知有效值”的约束 - 部分索引（
partialFilterExpression）对$ne无改善作用——它只加速“满足某条件”的子集，不解决否定语义本身
容易被忽略的连锁影响
一个 $ne 往往会拖垮整个查询链：
- 和
$and组合时，只有其他条件可能走索引，$ne部分仍强制全索引扫描 - 在聚合管道中用
$expr: {$ne: ["$field", "val"]}，同样无法下推，必然触发COLLSCAN - 配合
$or时，含$ne的分支直接放弃索引，优化器只能退回到最弱分支的执行计划 - 字段类型变更（如字符串改数字）后，旧索引残留 + 新值类型不匹配，会让
$ne查询彻底退化为COLLSCAN，且explain不报错，只悄悄变慢
索引不是万能胶，$ne 是 MongoDB 明确划出的“低效区”。真正省事的做法，是在数据建模阶段就拒绝存储需要靠 $ne 才能表达的状态。
