根本原因是mongodb默认返回完整文档，即使只查少量字段；应使用projection显式指定所需字段、为嵌套路径建索引、按访问模式拆分集合以避免全文档加载。
为什么 find() 会扫描整条文档？
MongoDB 默认返回匹配文档的全部字段，即使你只用其中一两个。如果文档很大（比如嵌套深、含数组或长文本），而查询又没限制字段，find() 就得把整个 BSON 文档从磁盘读入内存、解序列化、再传输——这直接拖慢响应、增加网络和内存开销。
用 projection 精确控制返回字段
在 find() 或 findOne() 中传入第二个参数（即 projection 对象），显式指定要返回的字段，能强制 MongoDB 只加载和传输必要数据。
-
{"name": 1, "email": 1, "_id": 0}表示只返回name和email，不返回_id -
{"logs": 0, "history": 0}表示排除大字段，其余全返回（慎用，易误伤） - 混合写法合法：
{"title": 1, "tags": 1, "content": 0}—— 显式包含 + 显式排除可共存，但不能混用1和0除_id外 - 对嵌套字段也有效：
{"profile.avatarUrl": 1, "profile.bio": 1}
嵌套数组里只取需要的元素：用 $elemMatch 或 $ 投影
当字段是数组，且你只关心满足条件的某一项时，全量返回整个数组会造成严重冗余。MongoDB 提供两种轻量投影方式：
Coding Agent Loops
下载
一款AI工具，主要用于在持久tmux会话中运行AI编码代理(Codex、Claude Code)，使用Ralph重试循环和完成钩子处理多步骤编码任务，适合需要提升相关任务效率的用户。
- 用
$操作符：如{"tags": {"$elemMatch": {"type": "featured"}}}配合 projection{"tags.$": 1}，只返回第一个匹配的tags元素 - 用
$elemMatch投影本身（聚合阶段）更灵活，但find()中只能用$实现单个匹配项提取 - 注意：
tags.$不支持多匹配结果；要取多个，必须用聚合管道 +$filter
设计阶段就该规避“大文档陷阱”
再好的 projection 也救不了设计失当的 schema。真正减少扫描，得从源头控制文档体积：
- 高频查询字段（如
status、updatedAt）和低频/大体积字段（如rawData、auditLog）拆到不同集合，用引用代替内嵌 - 避免在单文档中存储重复结构，例如用户评论列表 → 改为独立
comments集合，用userId和postId建索引 - 文本类字段（如
description）若非搜索必需，别建全文索引；确实要查，考虑用text索引 +$text查询，而非$regex全表扫 - 定期用
db.collection.stats()查看平均文档大小和avgObjectSize，超过 16MB（BSON 限制）前就得重构
字段扫描不是靠后期加 projection 就能彻底解决的问题——它暴露的是文档模型与访问模式是否对齐。越晚调整 schema，迁移成本越高，投影逻辑也越容易漏掉边界情况。
