$ne和$nin几乎不走索引，因二者均为范围语义且选择性低：$ne需扫描全索引排除匹配项，$nin被设计为不支持索引；配合$not、$exists、$where等操作符同样导致索引失效或降效。
$ne 查询为什么几乎不走索引
因为 $ne 本质上是范围语义，MongoDB 必须扫描整个索引（或集合）才能确认哪些文档“不等于”某个值。即使字段上有索引，引擎也无法跳过大量条目——它得逐条比对、排除，最终结果集往往覆盖大部分数据。
常见错误现象：db.users.find({status: {$ne: "inactive"}}) 在 status 字段建了索引，但 explain() 显示 executionStats.nReturned 接近全量，executionStats.totalDocsExamined 也接近总文档数。
- 单独使用
$ne基本等价于全表扫描，索引形同虚设 - 如果配合
$and，比如{status: {$ne: "inactive"}, age: {$gt: 18}}，只有age部分可能用上索引，status的$ne仍拖累整体效率 - 更糟的是：若索引为
{status: 1, age: 1}，$ne会让age字段的索引部分完全失效（后续字段不生效）
$nin 查询根本无法使用索引
$nin 不只是低效，而是被 MongoDB 明确设计为「不支持索引」的操作符。它的语义要求检查每个候选文档是否**全部不匹配**数组中任意一个值，这与 B-tree 索引的有序查找逻辑冲突。
使用场景里最容易踩坑的是：误以为给字段加了索引就能加速黑名单过滤，比如 db.orders.find({user_id: {$nin: [101, 102, 103]}})。
- 无论
user_id是否有单字段索引，$nin查询都会触发 collection scan - 即使数组只含 1 个元素，
{$nin: [101]}也等价于{$ne: 101}，同样绕过索引 - 替代方案只能是重构查询逻辑：用
$in查白名单 + 应用层取反，或引入标记字段（如is_blocked: true）做等值查询
哪些操作符和 $ne / $nin 一样危险
不是所有看似“简单”的操作符都友好。MongoDB 中一批查询谓词天生与索引不兼容，它们要么跳过索引，要么让索引利用率断崖下跌：
-
$not：和$ne类似，强制全索引扫描；若包裹$regex或$mod，情况更糟 -
$exists：索引中 null 和缺失字段存储方式一致，引擎必须读每个文档判断字段是否存在 -
$where：JS 表达式无法下推到存储层，必然 collection scan -
$or各分支独立走索引，但合并开销大；若任一分支含$ne或$nin，该分支直接放弃索引
真正能用索引的“否定”替代思路
想表达“非某类”，硬写 $ne 或 $nin 是最差解。实际可落地的优化路径很窄，但有效：
- 把否定逻辑移到应用层：先用
$in查出要排除的 ID 列表，再用内存 diff 过滤 - 增加冗余字段做正向标记，例如把
status != "deleted"改成is_active: true，然后建{is_active: 1}索引 - 对高频否定查询字段，考虑用 TTL 索引或 partial index 隔离活跃数据，让“默认查活跃”变成等值+范围组合
- 聚合阶段用
$facet或$setDifference实现逻辑否定，但注意这不能替代查询层索引优化
索引不是万能胶，$ne 和 $nin 是明确划出的雷区。越早接受“它们就是不能高效索引”，越少在 explain 里反复怀疑自己建错了索引。
