$limit 不会减少文档扫描量，因为它只是截断输出而非过滤数据；全表扫描由执行计划决定，$limit 仅在管道下游丢弃多余文档，真实扫描量需看 executionStats.totalDocsExamined。
$limit 不能提前终止全表扫描，因为它不是过滤器，而是“截断器”——它只控制输出数量，不参与数据读取决策。
为什么 $limit 不会减少文档扫描量？
MongoDB 的 $limit 阶段本身不触发索引下推，也不改变查询计划中“要读哪些文档”的逻辑。它只是在管道流中把已经进入该阶段的前 N 条文档放行，其余丢弃。如果前面没 $match 或索引能跳过大量文档，数据库仍需逐条读取、解码、送入管道，直到凑够 N 条或扫完整个集合。
- 全表扫描由执行计划（
IXSCAN或COLLSCAN）决定，而$limit出现在explain的stages里是下游阶段，不影响上游扫描行为 - 即使写成
[{$limit: 10}, {$match: {status: "active"}}]，优化器也不会用$limit帮你“少读”，因为$match在后，必须先拿到 10 条才能匹配——而这 10 条可能是任意文档，毫无业务意义 - 只有当
$match在前且命中索引时，扫描才真正收缩；$limit此时只是让后续$sort或$group处理更少数据
什么情况下 $limit 看似“生效了”，其实只是巧合？
比如集合只有 5 条文档，你写 {$limit: 10}，返回 5 条。这不是 $limit 起了作用，而是数据本来就不够。这种场景容易让人误判“$limit 缩减了 IO”，但换成百万级集合立刻暴露问题。
- 用
db.collection.aggregate([...], {explain: "executionStats"})查看executionStats.totalDocsExamined—— 这个值才是真实扫描量，和$limit参数无关 - 如果
totalDocsExamined和集合总文档数一致，说明没走索引、没过滤，$limit完全没缓解压力 - 常见错觉来源：应用层看到返回快了（因只传回 10 条），但数据库日志里
slowms依然很高，CPU/IO 持续打满
如何让 $limit 真正降低扫描开销？
关键不是挪动 $limit，而是确保它前面有能缩小数据集的阶段，且该阶段能利用索引。
- 把高选择性
$match放最前，并为对应字段建索引（如{userId: 1, createdAt: -1}） - 避免在
$limit前使用$project、$addFields等无过滤能力的阶段，它们只会增加 CPU 开销 - 若必须分页且数据无序，优先用“基于游标的分页”（如用上一页最后的
_id或时间戳做$match），而不是依赖$skip/$limit - 对排序后分页，确保
$sort字段有索引，否则$limit无法被合并进排序，内存排序仍会全量扫描
最容易被忽略的一点：聚合管道里的 $limit 从不改变“读多少”，只改变“传多少”。想省 IO，得靠 $match + 索引；想省内存，得靠 $sort 合并或 allowDiskUse；指望 $limit 自己扛起性能优化，等于让门卫去干保安队长的活。
