覆盖查询能减少磁盘i/o，因索引为内存中b-tree结构，仅含索引字段和_id（除非排除），当filter与projection完全命中同一索引时，mongodb无需加载文档，全程在索引中完成，跳过磁盘读取；判断依据是explain("executionstats")中totaldocsexamined=0且stage为ixscan或projection_covered。
覆盖查询为什么能减少磁盘 I/O
因为 MongoDB 的索引本身是独立存储的 B-tree 结构，只包含索引字段和 _id（除非显式排除）。当 find() 查询的 filter 和 projection 完全命中某个索引的所有字段时，MongoDB 就不必加载原始文档——整个查询在内存中的索引页里就能完成。这直接跳过了从磁盘读取 document 的步骤，I/O 量下降 90% 以上。
关键判断依据是执行 explain("executionStats") 后看这两个字段：
-
nReturned和totalDocsExamined相等（比如都是 127） -
executionStage是IXSCAN，且没有出现FETCH阶段
怎么写一个真正生效的覆盖查询
覆盖查询不是“加个 projection 就行”，它依赖索引结构与查询语句的严格匹配。必须同时满足：
- 查询条件（
filter）中所有字段，都在同一个索引里 - 投影字段（
projection）只包含该索引已有的字段（含_id），不能多也不能少 - 如果索引不含
_id，而 projection 显式写了_id: 1，就破坏覆盖——因为_id不在索引里，必须 FETCH 文档 - 如果索引是
{name: 1, email: 1}，但查询用了{name: "Alice", email: {$regex: "^a"}}，正则可能让索引失效，也就无法覆盖
示例：假设你建了这个索引
db.users.createIndex({ status: 1, createdAt: -1, name: 1 })
下面这个查询才是覆盖的：
db.users.find({ status: "active" }, { status: 1, createdAt: 1, name: 1, _id: 0 })
而下面这些都不是：
-
db.users.find({ status: "active" }, { status: 1, email: 1 })——email不在索引中 -
db.users.find({ status: "active", email: "a@b.com" }, { status: 1, createdAt: 1 })——email在 filter 里但不在索引中 -
db.users.find({ status: "active" }, { status: 1, createdAt: 1, _id: 1 })—— 索引没建_id，却要返回它
复合索引字段顺序对覆盖查询的影响
字段顺序决定索引能否支撑过滤 + 排序 + 投影三重需求。错误顺序会导致看似“字段都齐了”，实则无法覆盖。
- 等值查询字段（
{a: "x", b: "y"}）放最前 - 范围查询字段（
{c: {$gt: 10}}）放中间 - 排序字段（
.sort({d: -1})）可放最后，但仅当它是等值或范围之后的唯一排序依据 - 投影字段必须全部落在这个顺序链上；如果排序字段不在索引末尾，或用了多个方向（如
{d: 1, e: -1}），覆盖可能失效
反例：索引 {status: 1, amount: 1, paidAt: -1}
- ✅
find({status: "paid"}, {status: 1, amount: 1})—— 覆盖 - ✅
find({status: "paid", amount: {$gte: 100}}, {status: 1, amount: 1, paidAt: 1})—— 覆盖 - ❌
find({status: "paid"}, {status: 1, paidAt: 1})——paidAt在索引里但被跳过（中间有amount），无法跳过该字段直接取paidAt
聚合管道里也能做覆盖查询吗
可以，但限制更严。只有 $match + $project 两阶段，且 $project 只保留索引字段时，才可能触发覆盖。
注意：
-
$group、$sort、$lookup会强制 FETCH 文档，直接破坏覆盖 - 即使开头是
$match且条件全索引，只要后面有$addFields或计算字段，就不再覆盖 - 使用
explain("executionStats")查看聚合时，仍需确认executionStages中没有FETCH，且totalDocsExamined === nReturned
安全写法示例：
db.orders.aggregate([
{ $match: { userId: ObjectId("..."), status: "shipped" } },
{ $project: { userId: 1, status: 1, orderDate: 1, _id: 0 } }
])
前提是索引为 {userId: 1, status: 1, orderDate: 1}。
覆盖查询不是银弹——它只适用于“查得窄、返回少”的场景。一旦业务需要动态字段、全文搜索或复杂计算，就得权衡是否值得为覆盖而冗余建索引。最容易被忽略的一点是：索引本身也占内存和磁盘，字段越多、基数越低，索引膨胀越快。别为了覆盖几个字段，把 10 个低频字段全塞进一个索引里。
