MongoDB中sort()必须在limit()之前调用，否则排序无效；多字段排序需匹配索引前缀；limit(0)不限制，负数取绝对值；重复值排序须加唯一键（如_id）确保稳定性。
直接用 sort() 和 limit()，但顺序和索引决定性能与结果是否稳定。
sort() 必须在 limit() 之前调用
游标方法链式调用时，sort() 必须出现在 limit()（以及 skip()）之前。如果先 limit() 再 sort()，排序不会生效 —— MongoDB 只对实际返回的那批文档排序，而那批文档是未排序的随机子集。
- ✅ 正确：
collection.find().sort({length: -1}).limit(3) - ❌ 错误：
collection.find().limit(3).sort({length: -1})（等价于没排序） - ⚠️ 注意：即使迭代游标后再调用
sort()，也完全无效 —— 游标一旦开始消费，后续链式方法不再影响已生成的查询计划
多字段排序要匹配索引前缀
当 sort() 涉及多个字段（如 {author: 1, length: -1}），MongoDB 能否避免内存排序，取决于是否存在对应前缀的索引。
- 若只有
{author: 1}索引，sort({author: 1, length: -1})会触发内存排序（in-memory sort） - 若存在
{author: 1, length: -1}或{author: 1, length: 1}复合索引，则可直接利用索引顺序 - 方向不严格要求一致：索引
{a: 1, b: -1}支持sort({a: -1, b: 1})（整体反向），但不支持sort({a: 1, b: 1}) - 嵌套字段排序需用点号语法：
sort({"metadata.rating": -1})，对应索引也得建在{"metadata.rating": -1}
limit() 的数值陷阱和分页隐患
limit() 参数看似简单，但几个边界情况容易导致线上行为异常：
-
limit(0)等价于不限制，不是“返回零条” -
limit(-5)会被当作limit(5)处理（负数取绝对值） - 与
skip()组合做分页时，skip(10000).limit(20)会让 MongoDB 扫描并丢弃前 10000 条 —— 数据量大时极慢，应改用“基于游标”的分页（如用上一页最后一条的_id做查询条件） - 未配合
sort()直接limit()，结果顺序不可预测 —— 即使集合只有一条索引，也不保证物理存储顺序就是返回顺序
重复值排序必须加唯一键兜底
当排序字段存在大量重复值（比如几十万本书都 length: 1104），仅靠 sort({length: -1}) 返回顺序可能每次不同 —— MongoDB 不保证相同值内部的相对顺序。
- ✅ 稳定写法：
sort({length: -1, _id: 1})，用_id（通常唯一且递增）作为次要排序键 - ⚠️ 不推荐用
sort({length: -1}).skip(x).limit(y)实现分页 —— 重复值 + skip 容易跳过或重复返回同一批文档 - 如果业务允许，优先在应用层去重或用时间戳字段替代
_id，避免依赖 ObjectId 的隐式顺序
真正麻烦的不是语法写错，而是排序+限制组合后，线上查出来的数据“看起来对”，但换一批数据、换一个时间点就乱序或漏数 —— 这种问题往往要到分页错位或报表统计偏差时才暴露。
