根本原因是MongoDB必须完整解析整个BSON文档才能执行projection，即使只查status和updated_at；大数组导致解析开销剧增，Motor仅暴露该问题。
Motor 查询 MongoDB 大数组变慢，根本原因不是 Motor 本身，而是 MongoDB 加载文档时必须完整解析整个 BSON 文档——哪怕你只想要 status 和 updated_at。数组字段（如 logs、history）一旦达到几十 KB，每次 find() 都会触发内存与 CPU 峰值，Motor 只是忠实地把这压力暴露出来。
为什么 find() 一查大数组就卡住？
MongoDB 不会“跳过”未投影的字段；遇到大数组，它必须：
- 从磁盘/缓存读取整份文档
- 完整解码 BSON，包括逐个解析数组所有元素（哪怕你根本不用）
- 再按
projection过滤字段——这步发生在解析之后，无法省掉前面的开销
Motor 的异步封装不改变这个底层行为。现象上就是 await collection.find(...).to_list() 延迟陡增，explain("executionStats") 显示 totalDocsExamined 和 executionStages.stage 是 FETCH 而非 IXSCAN。
如何用复合索引 + 投影实现真正覆盖查询？
关键：让 MongoDB 完全不加载文档主体，只走索引。但数组字段本身不能进覆盖索引，所以得绕开它：
- 索引必须包含所有
filter字段 + 所有projection字段（含_id，如果返回了它） - 错误示例：
db.orders.createIndex({"items": 1, "status": 1})——items是数组，该索引无法覆盖 - 正确示例：
db.orders.createIndex({"status": 1, "updated_at": -1, "user_id": 1, "_id": 1}) - 查询时严格投影：
collection.find({"status": "shipped"}, {"status": 1, "updated_at": 1, "user_id": 1, "_id": 1})
Motor 中写法一致，无需额外适配。验证是否生效：看 explain("executionStats") 的 totalDocsExamined === 0 且 executionStages.stage === "IXSCAN"。
真要读数组内容时，怎么避免加载全部？
别让整个数组进结果。用 $slice 在 projection 里硬限长度，这是最轻量的控制手段：
- 只取前 5 条：
{"logs": {"$slice": 5}} - 取最后 3 条：
{"logs": {"$slice": -3}} - 配合索引效果更明显：比如已有
{"user_id": 1, "created_at": -1}索引，再加$slice，MongoDB 就能避开加载全部activities数组
注意：$slice 是 projection 操作，不影响索引匹配逻辑，但它直接减少传输和解析负担——Motor 异步接收的数据包体积立刻下降。
哪些坑 Motor 用户最容易踩？
Motor 本身不制造陷阱，但容易放大 MongoDB 的隐性规则：
- 投影里漏掉某个索引字段（比如索引含
_id，但 projection 没写_id: 1），MongoDB 立刻 fallback 到FETCH - 投影里多写了没索引的字段（比如
{"status": 1, "logs": 1}），哪怕logs是数组，也会强制加载文档 - 误以为
limit(10)能缓解大数组压力——它只限制返回文档数，不减少单个文档的解析开销
最常被忽略的是：覆盖查询的“全字段对齐”要求极其严格，差一个字段，就退回原始性能水平。调试时务必用 explain 看 totalDocsExamined，别只信代码写得“看起来对”。
