不能。mongodb对{$exists: false}查询永不走索引，因索引不存储字段缺失记录；{field: null}匹配null值和缺失字段，但执行计划通常为collscan，尤其缺失文档多时。
查 field: null 或 field: {$exists: false} 能不能走索引？
不能。MongoDB 对 {$exists: false} 查询永远不走索引，哪怕你在 field 上建了普通索引 —— 因为索引项里根本没存“字段不存在”的记录。而 {field: null} 行为模糊：它会匹配“值为 null”和“字段缺失”两类文档，但执行计划里大概率还是 COLLSCAN，尤其当集合里大量文档缺失该字段时，优化器直接放弃索引。
验证方式很简单：db.collection.find({field: {$exists: false}}).explain("executionStats")，看 executionStages.stage 是不是 COLLSCAN。
想让“字段缺失”查询变快，该建什么索引？
建稀疏索引（sparse: true）或部分索引（partialFilterExpression），但目的不是加速 $exists: false，而是绕开它：
- 如果业务中“字段缺失”是少数情况（比如只有 5% 文档没
phone），可以建稀疏索引：db.users.createIndex({phone: 1}, {sparse: true})，然后把查询逻辑反转：查“存在的”再取反（应用层做） - 更稳妥的是加标记字段，比如写入时统一设
phone_missing: true，再对它建普通索引：db.users.createIndex({phone_missing: 1})—— 这样{phone_missing: true}就能走索引 - 部分索引适合固定条件，例如只索引
status: "active"下的缺失字段：db.users.createIndex({email: 1}, {partialFilterExpression: {status: "active"}})
$exists: true 和 $eq: null 的索引行为差异
{field: {$exists: true}} 可以走索引，但有两个前提：一是字段在索引定义中（比如复合索引 {a: 1, field: 1}），二是该字段在大多数文档中都存在；否则优化器可能仍选全表扫描。
{field: {$eq: null}} 在有索引时能走，但它和 $exists: true 必须并列写才能精准命中“存在且值为 null”：{field: {$eq: null}, field: {$exists: true}}。单独用 {field: null} 不推荐 —— 它语义不清，且在唯一索引下会把缺失字段也当成 null 冲突，导致插入失败。
聚合管道里处理空值，索引还有效吗？
无效。一旦进聚合阶段（比如 $match 后接 $project），索引只在第一个 $match 阶段起作用。后续阶段如 $ifNull 或 $cond 都是内存计算，不触发索引。
所以别指望靠 $ifNull 来“兜底”缺失字段还能走索引。真正要提速，得把过滤逻辑尽量前移到首个 $match，且避免用 $exists: false —— 它在这里一样慢。
真正难处理的是混合场景：既要查“缺失”，又要高频排序或分页。这时候要么预建标记字段+索引，要么接受首次查询慢，后续靠内存缓存扛住。
