能，covered query仅在查询条件与投影字段（含显式排除的_id）全部被同一索引覆盖且索引常驻内存时，才可避免磁盘io；否则索引页未命中仍触发磁盘读。
什么是covered query，它真能避免磁盘IO？
能，但仅限于满足严格条件的查询——find() 返回的字段必须全部来自索引，且查询条件也完全由同一索引覆盖。MongoDB 会直接从内存中的索引页返回结果，跳过读取文档数据（即不访问 _id 对应的数据文件），从而避免磁盘IO。但这不是“绝对零IO”，因为索引本身可能不在内存中；若索引页未命中 page cache，仍会触发磁盘读。真正零IO的前提是：索引已常驻内存 + 查询完全被覆盖。
怎么写出一个真正的covered query？
关键在投影（projection）和索引设计的精确匹配。MongoDB 要求：查询谓词字段 + 投影字段 + _id（除非显式排除） 全部包含在同一个复合索引中，且 _id: 0 必须显式声明才能排除 _id（否则默认包含，导致无法覆盖）。
- 错误写法：
db.users.find({status: "active"}, {name: 1})—— 缺少_id字段，但没禁用，MongoDB 默认加回_id: 1，而索引若不含_id就破功 - 正确写法：
db.users.find({status: "active"}, {name: 1, _id: 0})，配合索引：db.users.createIndex({status: 1, name: 1}) - 注意：即使你只查
{status: "active"}且投影为空（{}），MongoDB 仍默认返回_id，所以必须写{_id: 0}才可能覆盖
如何验证查询是否真的covered？
靠 explain("executionStats") 中的 indexOnly 字段——但它在 4.2+ 已废弃；现在要看 executionStats.executionStages.stage === "IXSCAN" 且 executionStats.executionStages.isCovered === true。更直接的是检查 executionStats.totalDocsExamined === 0：如果为 0，说明没读任何文档，大概率是 covered（前提是没触发 $text、$near 等例外）。
示例验证命令：
db.users.find({status: "active"}, {name: 1, _id: 0}).explain("executionStats")，然后定位到 executionStages 节点下确认 isCovered 值。
容易被忽略的破坏covered的细节
很多看似无害的操作会悄悄让 covered 失效：
-
$sort用的字段不在索引里 → 引发 in-memory sort 或临时文件，且必然需要读文档 - 查询用了
$regex且非前缀模式（如/abc/）→ 索引失效，退化为 collection scan - 索引含稀疏字段，但查询命中了 null/missing 值 → 可能漏掉索引条目，MongoDB 为安全起见放弃 covered 优化
- 使用
hint()指定索引，但投影字段超出该索引范围 → 直接报错或降级为非covered - 集合启用了 collation，而索引未用相同 collation 创建 → 即使字段匹配，也不视为 covered
实际部署时，covered query 的收益高度依赖工作集大小和内存压力；一旦索引页被换出，再快的 covered 查询也会变慢——别只盯着执行计划，得盯住 mongostat 里的 faults 和 res。
