$limit不能放在$sort前，否则先随机截断再排序，结果不完整、不稳定且无法利用索引；仅当$sort后紧跟$limit时，优化器才合并二者以降低内存占用。
$limit 不能放在 $sort 前面，否则结果不可靠
语法上允许 $limit 出现在 $sort 前，但语义上错误：它会先随机截掉一部分文档，再对残缺数据排序。你拿到的不是全局 Top N，而是“某次随机抽样后的 Top N”，每次执行可能不同，且无法利用排序字段索引。
- 现象：
[{$limit: 10}, {$sort: {score: -1}}]返回的 10 条里，最高分可能是 82，而全量数据里实际有 97 分的文档被直接跳过了 - 索引失效：MongoDB 只能在
$sort输入是全量匹配结果时，用{score: -1}索引加速；$limit在前，$sort的输入已非原始集合，索引不参与排序过程 - 唯一合理例外：仅用于调试，比如快速看几条原始文档结构，不关心顺序或代表性
$sort 和 $limit 相邻时，MongoDB 会自动合并优化
当 $sort 后紧跟 $limit（中间无 $project、$addFields 等干预），MongoDB 优化器会把 $limit “吸进” $sort 阶段，让 $sort 只维护前 N 个元素，而不是全量排序再截断。
- 好处：内存占用从 O(n) 降到 O(N)，N 是 limit 值；即使数据量大，只要 N 小，就能避免
Sort exceeded memory limit - 验证方式：用
{explain: true}查看执行计划，在$sort阶段的输出里找"limit": 5字段是否存在 - 注意：这个优化只在
$sort→$limit顺序下触发；反过来或中间插了其他阶段，就不会合并
分页场景下，$skip 和 $limit 必须放在管道末尾
分页不是“先取再跳”，而是“先完整聚合，再切片”。把 $skip 或 $limit 放在 $group、$lookup 前，会提前丢弃原始文档，导致聚合结果错误。
- 典型错误：
[{$skip: 20}, {$limit: 10}, {$group: {...}}]—— 先扔掉 20 条原始数据，再聚合，总数和分布全歪了 - 正确顺序：
$match→$sort→$group→$skip→$limit（$sort必须在$skip前，否则分页无序） - 深度分页警告：用
$skip跳过 10 万条再取 10 条，性能极差；应改用游标分页（如基于_id或排序键的范围查询）
多字段排序必须加 _id 才能保证结果稳定
$sort 对重复值不承诺稳定顺序。如果只按 {score: -1} 排序，两个 score=95 的文档在多次查询中可能交换位置——前端列表“闪动”，导出数据不一致。
- 根本原因：MongoDB 不维护相同排序键下的插入/存储顺序，尤其在有并发写入时
- 解决办法：在
$sort中显式加入唯一字段，最稳妥的是_id，例如{$sort: {score: -1, _id: 1}} - 配套动作：为该组合建索引，如
db.col.createIndex({score: -1, _id: 1})，否则排序仍可能走内存、爆限
$limit 和 $sort 的位置会同时影响结果正确性、索引使用率、内存消耗和执行稳定性——这四个维度一旦错一个，线上就容易出静默故障。 
