$exists:true 默认不走索引，需创建部分索引（如{status:1}配合partialFilterExpression:{status:{$exists:true}}）才能命中索引；稀疏索引不可靠，部分索引是更可控的解决方案。
$exists 查询默认不走索引，除非你显式创建匹配的索引。MongoDB 的 $exists:true 本身不会触发索引扫描，它本质上是字段存在性检查，而标准单字段索引（如 {field: 1}）对 $exists:true 是无效的——即使该字段被索引，查询仍可能全表扫描。
为什么 $exists:true 不自动利用普通索引
MongoDB 索引只存储有值的键值对；如果一个文档根本没这个字段，索引里就完全不存这条记录。所以当你执行 {status: {$exists: true}}，引擎无法靠索引“跳过”缺失字段的文档——它得先确认哪些文档含该字段，而这在普通索引中没有元信息支持。
- 普通索引（
{status: 1}）只包含status有值的文档条目，不含status缺失的文档 - 因此
$exists:true查询无法用该索引“快速定位”，只能 fallback 到 collection scan -
$exists:false更糟：它要找“索引里没有的文档”，引擎必须遍历所有文档才能确认字段缺失
用部分索引（partial index）让 $exists:true 走索引
部分索引能明确告诉 MongoDB：“只索引那些满足某条件的文档”。对 $exists:true 场景，最直接的方式就是基于字段非空建部分索引。
- 创建方式：
db.collection.createIndex({status: 1}, {partialFilterExpression: {status: {$exists: true}}}) - 这个索引只包含
status字段存在的文档，体积更小、查询更快 - 执行
db.collection.find({status: {$exists: true}})时，MongoDB 会命中该部分索引（可通过explain("executionStats")验证） - 注意：不能用
{$exists: false}做partialFilterExpression，MongoDB 明确禁止该写法
$exists 与稀疏索引（sparse index）的区别
稀疏索引看起来像解法，但它和部分索引不是一回事，且有隐藏风险：
- 稀疏索引（
{status: 1, sparse: true}）也只索引含status的文档，但它是“被动忽略缺失字段”，不带过滤语义 - 它**不能保证**
$exists:true查询一定走索引——优化器可能仍选 collection scan，尤其当集合中大部分文档都含该字段时 - 稀疏索引不支持唯一约束与
$exists:false组合使用，容易在数据写入时出错 - 部分索引是更可控、更明确的选择；稀疏索引已逐渐被官方建议用部分索引替代
实际部署要注意的坑
部分索引虽好，但上线前必须验证真实行为，不能只看语法正确：
- 用
db.collection.explain("executionStats").find({status: {$exists: true}})查看executionStages.stage是否为IXSCAN，且nReturned与totalDocsExamined接近（说明没回退到 collection scan） - 部分索引不继承父索引的排序能力；若查询还带
.sort({status: 1})，需确认该索引是否覆盖排序需求 - 字段值为
null的文档会被包含在$exists:true结果中，也会被纳入部分索引——这符合预期，但业务上需确认是否真要包含null - 索引名最好体现用途，比如
idx_status_exists，避免后期维护时误删
真正起作用的从来不是 $exists 本身，而是你如何用部分索引把它“框进索引范围”。别指望 MongoDB 自动优化这个操作符，它的索引友好性完全取决于你是否主动构造了对应的索引结构。
