$not 通常触发全表扫描，因其无法转化为索引可优化的键范围，且匹配缺失字段（索引不包含），导致优化器放弃索引；应优先用正向条件重写或复合索引配合高选择性字段前置。
为什么 $not 通常触发全表扫描
$not 不是“取反索引”，它本身不直接参与索引匹配。MongoDB 查询优化器面对 {field: {$not: {$gt: 100}}} 这类表达式时，无法将“不满足 >100”转化为一组可利用 B 树索引快速定位的键范围；相反，它往往退化为：先用索引查出所有 field > 100 的文档 ID，再从全集合中排除这些 ID——而排除操作无法下推到索引层，最终仍需遍历大量文档。
更麻烦的是，$not 会匹配缺失该字段的文档（这是语义定义决定的），这进一步削弱了索引可用性：索引默认不包含缺失字段的条目，所以优化器干脆放弃索引走 collection scan。
用正向条件重写 $not 查询的实际效果
把 $not 拆成明确的、可索引的正向范围，几乎总是更快。比如：
- 原查询：
db.users.find({status: {$not: {$in: ["inactive", "banned"]}}})→ 可能全表扫 - 重写后：
db.users.find({status: {$in: ["active", "pending", "locked"]}})→ 若status有索引，直接走索引查找
注意：这个重写成立的前提是你**完全掌握 status 的所有合法值**。如果业务上 status 是开放枚举（比如允许新增 "on_leave"），硬编码白名单就不可靠。此时应评估是否真需要 $not，或改用应用层过滤。
什么时候可以给 $not 字段建索引？
单独为 $not 字段建索引没意义，但复合索引可能帮上忙——前提是 $not 条件和其他强筛选条件共存，且满足最左前缀原则：
- 错误示例：
db.logs.find({level: {$not: {$eq: "DEBUG"}}, timestamp: {$gt: ISODate("2026-05-01")}})→ 即使level和timestamp都有单列索引，优化器大概率不用 - 有效索引：
db.logs.createIndex({timestamp: 1, level: 1})→ 查询改写为{timestamp: {$gt: ...}, level: {$ne: "DEBUG"}}，此时timestamp走范围扫描，level在内存中过滤，比全表扫好得多
关键点：索引必须把高选择性、确定性高的字段放左边；$not 或 $ne 字段只能放在右边，作为“收口过滤”，不能指望它驱动索引扫描。
容易被忽略的陷阱：$not + $exists 组合
写 {email: {$not: {$exists: true}}} 看似合理，实际等于查所有 email 字段缺失或为 null 的文档。但 MongoDB 索引默认跳过 null 和缺失字段，所以这个查询 100% 全表扫。
更糟的是，如果集合里有大量 email 为 null 的文档（而非缺失），你可能误以为索引生效了——其实只是碰巧数据分布让你没立刻发现性能崩塌。真正可靠的替代方案是：
- 统一用
null表示“无邮箱”，并加一个稀疏索引：db.users.createIndex({email: 1}, {sparse: true})，然后查{email: null} - 或在写入时补全字段，让 schema 更稳定，避免
$exists类操作
复杂点在于：$not 的语义模糊性会传染到整个查询计划。它不像 $in 或 $gt 那样有清晰的索引友好边界，一旦出现，就得通盘检查字段语义、数据分布和索引结构——而不是只盯着那个 $not 表达式本身。
