覆盖索引能跳过磁盘读取，因MongoDB的B-tree索引仅含索引字段和_id，当filter与projection完全命中同一索引时，引擎直接在内存索引中完成查询，无需加载文档；验证标准为explain("executionStats")中totalDocsExamined=0且stage为IXSCAN或PROJECTION_COVERED。
覆盖索引本身不等于“纯内存计算”，但它能让 MongoDB 在绝大多数场景下完全避开磁盘 I/O——只要索引足够热（常驻内存），整个查询就真正在内存中完成。
为什么覆盖索引能跳过磁盘读取
MongoDB 的 B-tree 索引是独立存储的结构，只包含索引字段值 + _id（除非建索引时显式排除）。当 find() 的 filter 和 projection 字段全部命中同一索引时，引擎无需加载任何文档：索引节点里已有全部要返回的数据，直接组装结果即可。
- 关键前提是索引页必须已在内存（即被缓存到 WiredTiger cache 中）；否则仍会触发磁盘页加载——但这是 OS/存储层行为，不是 MongoDB 主动读文档
- 验证方式唯一：
explain("executionStats")中totalDocsExamined必须为0，且executionStages.stage是IXSCAN或PROJECTION_COVERED，不能出现FETCH - WiredTiger 默认将索引和数据分开缓存，索引通常更小、更易常驻；所以“索引热”比“文档热”更容易达成
哪些操作会强制退出纯索引路径
即使索引字段齐全，以下情况也会让 MongoDB 放弃覆盖逻辑，转而加载文档做后过滤：
-
$regex非前缀匹配（如/abc/而非/^abc/） - 范围查询（
$gt、$lt、$in）在复合索引中未处于最右位置，导致后续字段无法用于投影 -
$ne、$nin、$not基本无法触发覆盖，B-tree 无法高效跳过不匹配项 - 显式投影了
_id: 1，但索引未包含_id（比如建索引时用了{a: 1, b: 1, _id: 0}） - 使用
$text或地理空间索引时，覆盖查询不生效
如何验证是否真正在内存中跑完
别只信 explain() 输出，要结合运行时指标看实际行为：
- 查
serverStatus中的wiredTiger.cache段：确认bytes currently in the cache足够容纳索引大小 - 用
db.collection.stats()看索引总大小（totalSize字段），对比 cache 容量 - 监控
mongostat的netIn/netOut：覆盖查询网络传输量极小；若netOut明显偏高，说明返回了大量冗余字段或没走覆盖 - 事务内更要小心：用
session.startTransaction()包住explain()，否则看到的可能是非事务路径的执行计划
真正难的不是建对索引，而是让查询条件、投影字段、索引顺序三者严丝合缝地咬合——漏掉一个字段、错一位顺序、多投一个 _id，都会让整个优化失效。线上查慢，先盯 totalDocsExamined 是否为 0，再看 stage 是不是 IXSCAN，其余都是障眼法。
