find()加projection仍可能传输大量数据，因为非索引覆盖查询需回表读取完整文档再裁剪；只有当索引包含全部查询条件、投影字段（含_id控制），且explain显示totalDocsExamined为0时，才真正避免文档读取。
为什么 find() 加 { projection } 仍可能传输大量数据？
因为默认情况下，MongoDB 只在索引覆盖（index-covered）查询时才完全避免文档读取。如果查询条件或投影字段没被同一索引“全包含”，服务端仍需回表读取完整文档，再做字段裁剪——这部分文档数据会走网络传给客户端，哪怕你只想要两个字段。
关键判断标准：explain("executionStats") 中出现 "executionStage": "IXSCAN" 且 "totalDocsExamined": 0，才表示真正只查了索引、没碰文档。
- 索引必须包含所有
query条件字段 + 所有projection字段（含_id，除非显式排除） - 不能含数组展开（
$elemMatch、.0等）、正则部分匹配、$text、$near等触发文档加载的操作 - 排序字段也必须包含在该索引中，否则会多一次内存/磁盘排序，甚至退化为
COLLSCAN
如何构造一个真正覆盖查询的复合索引？
假设集合 orders 有字段：status、user_id、amount、created_at，你想查「已完成订单的用户ID和金额」：
db.orders.find(
{ status: "done" },
{ projection: { user_id: 1, amount: 1, _id: 0 } }
)这个查询要索引覆盖，必须建索引同时包含 status（查询条件）、user_id、amount（投影字段），且不依赖 _id（因已设 _id: 0）。推荐顺序：status（等值在前）→ 其他投影字段（按使用频率或大小排）：
db.orders.createIndex({ status: 1, user_id: 1, amount: 1 })- 别把
created_at塞进这个索引——它没在查询或投影里，徒增索引体积和写开销 - 如果后续还要按
created_at排序，得加到索引末尾：{ status: 1, user_id: 1, amount: 1, created_at: 1 }，否则排序无法用索引完成 - 注意：索引字段顺序影响覆盖能力。把
user_id: 1放status: 1前面，等值查询status就无法高效跳转
_id 字段在投影中到底要不要显式控制？
默认所有 find() 结果都带 _id，哪怕你没写。如果投影里没提它，MongoDB 仍会从文档中读出来再返回——这直接破坏索引覆盖。所以必须明确声明：
- 要
_id：不用写，但索引里必须包含它（即建索引时得有_id: 1字段） - 不要
_id：必须写{ _id: 0, user_id: 1, amount: 1 }，且索引里**不能含**_id（否则索引变大，无收益） - 混合场景慎用：
{ _id: 0, tags: 1 }要求索引覆盖tags，但如果tags是数组，tags.0这种投影仍会触发文档读取
验证方式：执行 db.orders.find(...).explain("executionStats")，确认 "totalDocsExamined" 为 0，且 "executionStages.stage" 是纯 IXSCAN。
聚合管道里怎么安全地做索引投影？
aggregate() 比 find() 更容易意外破环覆盖，尤其当用了 $project、$addFields 或表达式时。只有最简形式能走索引覆盖：
db.orders.aggregate([
{ $match: { status: "done" } },
{ $project: { user_id: 1, amount: 1, _id: 0 } }
])-
$match阶段的条件字段 +$project输出字段，必须全部落在同一个索引里 - 一旦加了
$sort，就必须确保排序字段也在该索引中，否则会先 IXSCAN 再内存排序，"totalDocsExamined"可能飙升 - 避免任何计算字段：
{ total: { $add: ["$amount", 10] } }必须读文档，索引失效 - 4.2+ 支持
$lookup的let+pipeline内嵌匹配，但内层若没独立覆盖索引，依然会放大传输量
真正压低网络开销的核心，从来不是“写了 projection”，而是让 MongoDB 连文档磁盘页都不用打开——这要求索引设计、查询写法、聚合阶段三者严丝合缝。稍有错位，explain 里那个 "totalDocsExamined" 就会暴露真相。
