覆盖索引未被使用，是因为查询字段、投影字段或排序逻辑不匹配；通过explain("executionStats")中winningPlan.stage是否为IXSCAN且无FETCH、totalDocsExamined是否为0、nReturned是否等于totalKeysExamined来判断。
覆盖索引没被用上，不是索引建错了，而是查询字段、投影字段或排序逻辑不匹配 —— explain("executionStats") 里的 winningPlan 阶段会直接告诉你它到底在干什么。
怎么看 winningPlan 是否走的是覆盖索引
覆盖索引（Covered Query）要求：查询条件、排序字段、投影字段（find({a:1}, {b:1, c:1}) 中的 {b:1, c:1}）全部被同一个索引“覆盖”，且不需回表（即不出现 FETCH 阶段）。
关键判断点：
- 如果
winningPlan.stage === "IXSCAN"且没有inputStage或其父节点是IXSCAN自身（即无FETCH），才可能是覆盖索引 - 一旦出现
"stage": "FETCH"，说明 MongoDB 扫完索引后还得去磁盘查文档，已脱离覆盖场景 - 检查
winningPlan.indexBounds和executionStats.nReturned === executionStats.totalKeysExamined：若相等且totalDocsExamined === 0，大概率是覆盖；若totalDocsExamined > 0，一定不是
常见导致覆盖失效的写法
即使索引存在且结构合理，以下情况仍会让 winningPlan 跳过覆盖路径：
-
find({a: 1}, {a: 1, b: 1}).sort({c: 1})：排序字段c不在索引中 → 引入SORT阶段，强制 FETCH 后内存排序 -
find({a: 1}, {_id: 0, a: 1, b: 1})：显式排除_id会破坏覆盖（MongoDB 默认索引含_id，但投影排除后需 FETCH 补全） -
find({a: {$in: [1,2]}}, {a:1, b:1})：某些版本对$in多值范围不触发纯 IXSCAN，尤其当索引非前缀匹配时 - 复合索引为
{a:1, b:1}，但查询用了find({b: 5}, {b:1})：缺少前导字段a→ 只能 COLLSCAN 或用其他索引，无法覆盖
explain 输出里必须核对的三个字段
别只看 winningPlan.stage，这三个字段组合才能下结论：
-
executionStats.totalDocsExamined：必须为0。大于 0 = 拿了索引键还去磁盘捞文档 -
executionStats.nReturned：应等于totalKeysExamined（说明每条索引键都直接返回，没丢弃也没补） -
winningPlan.keyPattern：确认该索引确实包含所有查询条件、投影字段、排序字段（顺序也要注意：排序字段需紧跟查询前缀，且方向一致）
分片集群下覆盖索引的隐藏陷阱
在分片环境中，winningPlan 可能显示 "stage": "SHARD_MERGE" 或嵌套 "shards" 数组，此时单个分片的计划可能覆盖，但合并层会引入额外开销：
- 若
queryPlanner.winningPlan.shards存在，需逐个展开看每个分片的winningPlan—— 任一分片未覆盖，整体就不算覆盖查询 - 分片键不在索引中？即使局部满足覆盖，MongoDB 可能因路由不确定性放弃 IXSCAN，退化为广播查询
-
executionStats中的executionTimeMillis是协调节点耗时，不反映单分片真实 IO，容易误判“很快所以应该覆盖”
真正难的不是建索引，是让 MongoDB 相信「这组字段我全有，一个字节都不用去磁盘拿」——而 winningPlan 就是它给你的唯一证词。每次怀疑没走覆盖，先盯死 totalDocsExamined 和 stage 链，比反复重建索引更省时间。
