索引覆盖查询指查询条件和投影字段全部被同一索引包含，MongoDB可仅扫描索引返回结果，避免二次查找文档；其核心是减少I/O，提升性能，验证需依赖explain中"totalDocsExamined": 0且执行阶段为IXSCAN。
什么是索引覆盖查询，为什么能避免回表
MongoDB 的“回表”不是传统关系型数据库里的概念，但行为类似：当查询字段不在索引中时，MongoDB 必须先用索引定位文档 ID（或 _id），再根据 ID 去磁盘或内存里读取完整文档。这个二次查找就是性能瓶颈。索引覆盖查询（covered query）指所有查询条件 + 投影字段（find() 中的 projection）都完全被同一个索引包含，此时 MongoDB 只需扫描索引就能返回结果，不访问文档本身。
关键判断标准：explain("executionStats") 中出现 "indexOnly": true（旧版）或 "totalDocsExamined": 0（3.2+），且 "executionStages.stage" 是 "IXSCAN" 而非 "FETCH"。
如何构造能覆盖查询的复合索引
索引字段顺序直接影响覆盖能力，必须同时满足查询条件和投影字段：
- 查询条件字段（
filter）放前面，按等值 → 范围 → 排序字段顺序排列 - 投影字段（
projection）必须全部出现在索引中，且不能有$text、$expr等无法索引的表达式 -
_id字段默认包含在索引中，但如果投影里显式要求_id: 0，则索引不必包含它；反之若投影含_id: 1（默认），索引可不显式加_id，但要注意：如果索引没建在_id上，而查询又用了_id条件，它仍算作索引字段的一部分
示例场景：查用户昵称和邮箱，条件是状态 = "active" 且注册时间 > 某个日期
要覆盖，索引至少得是：db.users.createIndex({ status: 1, createdAt: 1, nickname: 1, email: 1 })
注意：不能把 nickname 放 createdAt 前面，否则范围查询（createdAt: { $gt: ... }）后无法高效利用后续等值字段。
常见踩坑：看着覆盖了，实际还是回表
- 投影里用了
$slice、$elemMatch 或字段路径含数组嵌套（如 "address.city"），即使索引包含该路径，MongoDB 也可能无法覆盖——因为索引存储的是数组展开后的多个键值对，无法精确还原原始结构
- 查询用了
$or，且各分支涉及不同字段，很难被单个索引覆盖；MongoDB 会尝试索引合并，但不会触发 indexOnly
- 启用了通配符索引（wildcard index），它不支持覆盖查询
- 集合启用了加密（Queryable Encryption），加密字段无法被索引覆盖
- 使用了聚合管道，
$project 阶段哪怕只取索引字段，只要前面有 $lookup 或 $unwind，就不可能覆盖
$slice、$elemMatch 或字段路径含数组嵌套（如 "address.city"），即使索引包含该路径，MongoDB 也可能无法覆盖——因为索引存储的是数组展开后的多个键值对，无法精确还原原始结构$or，且各分支涉及不同字段，很难被单个索引覆盖；MongoDB 会尝试索引合并，但不会触发 indexOnly
$project 阶段哪怕只取索引字段，只要前面有 $lookup 或 $unwind，就不可能覆盖验证方式永远以 explain("executionStats") 输出为准，别信“字段都在索引里”这种直觉。
覆盖查询对写性能和索引大小的影响
覆盖查询本质是用空间换时间：索引越大，越容易覆盖，但写入开销越高。
- 每多一个字段加入索引，插入/更新都要同步写索引项，尤其是高基数字段（如
email）会让索引体积显著膨胀 - 复合索引字段超过 3–4 个后，维护成本上升明显；优先保障高频查询路径，而不是“把所有可能投影的字段都塞进去”
- 如果查询经常变动投影字段，不如建多个精简索引（比如一个用于
{ status, name }查询，另一个用于{ status, email }），比一个大而全的索引更可控
真正难的不是建索引，是权衡哪些查询值得覆盖、哪些可以接受 FETCH。线上集合一旦数据量上去，删改索引都得评估锁和复制延迟。
