真正的覆盖查询指查询条件和投影字段全部包含在同一索引中且不使用否定等不支持操作符，使MongoDB无需读取文档本体即可返回结果。
覆盖索引能完全避免回表，但前提是查询字段和过滤字段都严格落在同一个索引里 —— 少一个字段、多一个字段、或者用了 $ne/$not 这类否定操作，都会让覆盖失效。
什么是真正的覆盖查询？
MongoDB 的覆盖查询（covered query）不是“用了索引就叫覆盖”，而是指整个查询过程连文档本体都不用读 —— 所有需要的数据，全从索引节点里直接拿。这依赖两个硬性条件：
- 查询条件中所有字段（
find()的 filter 部分）必须是索引的一部分 -
projection中返回的所有字段（包括隐式字段如_id）也必须全部包含在该索引中 - 不能使用任何无法被索引支持的操作符，比如
$regex（无锚点）、$ne、$exists: false、$text等
例如：你建了复合索引 {name: 1, email: 1, status: 1}，那么下面这个查询才可能覆盖：
db.users.find(
{name: "Alice", status: "active"},
{email: 1, _id: 0}
)
注意：_id: 0 是必须的，否则默认返回 _id，而它不在索引里 —— 这个细节很多人漏掉，结果 explain() 显示 IXSCAN 但仍是 DOCS_EXAMINED > 0。
为什么 select * 永远无法覆盖？
这是最常踩的坑：db.collection.find({a: 1}) 默认返回全部字段，等价于 {_id: 1, a: 1, b: 1, c: 1, ...}。只要索引没包含集合里所有字段（现实中不可能），就必然要回表读文档。
- 哪怕你只查
{a: 1}，但没显式写{a: 1, _id: 0}，MongoDB 仍会默认带上_id - 如果业务真需要多个字段，宁可显式投影，也不要依赖
*或省略 projection - 验证是否覆盖，看
explain("executionStats")中的totalDocsExamined是否为0，而不是只看stage === "IXSCAN"
复合索引字段顺序怎么排才利于覆盖？
覆盖不只看“有没有”，更要看“能不能用上”。字段顺序决定 B+ 树的层级排序逻辑：
- 等值查询字段（
{a: 1, b: 1}）建议放前面，范围查询字段（c: {$gt: 5}）放后面 —— 因为 B+ 树只能对最后一个范围字段做高效区间扫描 - 投影字段尽量靠前，尤其是高频返回的字段；MongoDB 从左到右匹配索引项，提前命中能减少内部遍历
- 不要为了覆盖强行把几十个字段塞进一个索引 —— 索引体积膨胀会拖慢写入，且
indexSize增长后内存压力明显
比如用户查询常用 name + status 过滤，返回 email 和 phone，那就建 {name: 1, status: 1, email: 1, phone: 1}，而不是反过来。
部分索引 + 覆盖 = 更精准的覆盖场景
当集合里大量数据不符合你的高频查询模式时，用部分索引能缩小索引体积，同时保持覆盖能力。例如只对激活用户建覆盖索引：
db.users.createIndex(
{name: 1, email: 1},
{partialFilterExpression: {status: "active"}}
)
此时 db.users.find({name: "Bob", status: "active"}, {email: 1, _id: 0}) 依然能覆盖，但索引只存 status === "active" 的记录，节省空间且提升扫描效率。
注意：partialFilterExpression 中的字段也必须包含在索引键里，否则无法生效；而且查询 filter 必须能被该表达式逻辑蕴含（比如索引写了 {status: "active"}，你就不能查 {status: {$in: ["active", "pending"]}}）。
覆盖索引最脆弱的地方在于“隐式依赖”——你以为字段都在索引里，但忘了 _id、忘了 $or 会破坏覆盖、忘了部分索引的 filter 表达式没兜住查询条件。每次加索引后，务必用 explain() 看 totalDocsExamined 和 executionStages.stage，别信直觉。
