$limit不能减少数据扫描量，因为它只限制传递给下一阶段的文档数量，不改变前序阶段的数据读取和处理行为，对磁盘I/O、索引扫描范围、内存消耗几乎无影响。
为什么$limit不能减少数据扫描量
$limit 只控制传递给下一阶段的文档数量，不改变前序阶段的数据读取和处理行为。它对磁盘 I/O、索引扫描范围、内存消耗几乎无影响——MongoDB 仍需完整执行前面所有阶段，再丢弃超出限制的文档。
常见错误是把 $limit 放在 $group 或 $lookup 后面，以为能“提前截断”，结果发现查询依然慢得离谱。真实瓶颈往往在 $lookup 关联了上万条记录，或 $unwind 展开后中间数据暴增十倍，此时 $limit: 10 只是最后扔掉 9990 条，毫无优化价值。
-
$limit本身不触发索引，也不跳过磁盘读取 - 它只作用于管道中“已生成”的文档流，不是“未生成”的候选集
- 若前序有
$sort，且没加唯一排序字段（如_id），$limit结果可能每次都不一致
真正能减少扫描的替代方案
想降低聚合时的数据扫描量，必须把过滤和裁剪动作往前移：
- 用
$match尽早过滤：比如在$lookup前加$match，避免关联全量集合；在$unwind前加$match，缩小数组展开范围 - 用
$project提前剔除大字段：如{"logs": 0, "rawData": 0}，减少 BSON 解析和内存占用 - 对
$lookup的 from 集合单独建索引：尤其在 on 字段和后续$match字段上建复合索引 - 用
$facet替代多轮聚合：避免重复扫描同一集合多次
例如，要查“最近 10 条用户订单及对应商品信息”，不要写成：[$lookup, $unwind, $sort, $limit]；而应：[$match: {createdAt: {$gt: ...}}, $sort, $limit, $lookup] —— 先筛出 10 条订单，再关联商品，而非先关联全部再截断。
$limit 和 $sort 组合时的隐性陷阱
当 $sort 后紧跟 $limit，MongoDB 会尝试内存优化（只保留 top-N），但前提是 $sort 字段有索引且不含重复值。否则：
- 若按
status排序（只有 “pending”/“done” 两种值），$limit: 10可能每次返回不同文档 - 必须显式加入
_id或其他唯一字段：如{$sort: {status: 1, _id: 1}} - 若
$sort字段无索引，即使加了$limit，MongoDB 仍要全表扫描+内存排序
验证方式：运行 .explain("executionStats")，看 nReturned 是否接近 totalDocsExamined —— 如果二者相差巨大，说明 $limit 没起到预期作用，问题出在前置阶段。
分页场景下 $limit + $skip 的性能真相
$skip 和 $limit 一起用（如分页第 100 页 × 每页 20 条）时，$skip: 2000 会强制 MongoDB 生成并丢弃前 2000 条结果。哪怕 $group 后只剩 500 条，只要管道逻辑上“可能产出 2000 条以上”，它就得模拟生成过程。
- 没有索引能加速
$skip，它完全依赖前序阶段输出量 - 真实卡点常藏在
$unwind或$lookup：一个订单含 50 个商品，$unwind后数据量翻 50 倍，$skip成本指数级上升 - 替代方案：用游标分页（
$gt+ 上一页末尾_id），彻底避开$skip
复杂点在于，schema 设计决定了你能不能用游标分页——如果排序依据字段不唯一、不可靠（比如时间戳精度不足），游标就失效，只能硬扛 $skip。这时候，$limit 不是优化手段，而是掩盖问题的临时补丁。
