覆盖索引失效的最常见原因是_id字段被隐式返回且未包含在索引中；mongodb默认返回_id，若索引不含它或投影未显式排除（_id: 0），则触发fetch阶段，导致回表查询。
覆盖索引失效的最常见原因，是 _id 字段被隐式返回且未被索引包含。 MongoDB 默认总是返回 _id，哪怕你没写进投影；只要索引里没它，就必然触发文档加载（FETCH 阶段），覆盖查询直接破功。
为什么 find() 明明用了索引却还是读了文档？
根本判断依据不是“有没有索引”，而是执行计划里 executionStats.stage 是否为 IXSCAN 且 executionStats.nReturned === executionStats.keysExamined。一旦出现 FETCH 阶段，说明索引没覆盖全：
-
_id: 0没显式写出 —— 这是最高频踩坑点；复合索引几乎都不含_id，不屏蔽就会回表 - 查询条件或投影字段有任一不在索引中，比如
{title: 1, status: 1}索引，但查询写了{title: "abc", category: "x"}，category不在索引里 → 必须 FETCH - 用了
$regex且没前缀锚定（如^ABC），或用了$ne、$not、$where、$text等强制全扫描操作符，索引直接降级为范围扫描甚至 COLLSCAN - 分片集群下，
mongos无法精确下推条件（比如跨分片$or或不含分片键的查询），会广播到所有分片，即使单个分片上满足覆盖条件，整体仍可能触发 FETCH
如何验证是否真正在用覆盖索引？
别信直觉，必须跑 explain("executionStats") 看真实执行路径：
- 检查
executionStats.stage：必须是IXSCAN，不能出现FETCH或COLLSCAN - 对比
keysExamined和docsExamined：二者必须严格相等，且等于nReturned - 确认
executionStats.indexesUsed列出的索引，确实包含了全部查询字段 + 投影字段（不含_id的话） - 注意：MongoDB 6.0+ 的
explain输出里已移除indexOnly字段，它不再可靠，以 stage 和 counts 为准
ESR顺序和复合索引设计陷阱
覆盖查询要求索引字段顺序符合 ESR（Equality, Sort, Range）原则，否则即使字段全在索引中，也可能无法跳过 FETCH：
- 等值查询字段（
{status: "active"}）必须放最前 - 排序字段（
{sort: {created_at: 1}}）居中，且必须和索引方向一致 - 范围字段（
{age: {$gt: 18}}）放最后；$in被视为范围操作，不能“穿透”到后续字段做等值匹配 - 示例：索引
{status: 1, created_at: 1, age: 1}可覆盖find({status: "active"}, {status: 1, created_at: 1, _id: 0}).sort({created_at: 1})；但如果加了{age: {$gt: 25}}，且age不在索引末尾，就可能失效
真正难的不是建索引，而是让 MongoDB 在复杂查询条件下依然信任那个索引——它对字段顺序、投影控制、操作符兼容性极其敏感。漏掉 _id: 0 或错放一个 $in，前面所有优化都白搭。
