MongoDB的sort()要走索引加速，必须确保排序字段的顺序、方向与复合索引严格一致，等值查询字段置前，范围查询后置，并用\_id兜底保障排序稳定性。
sort()字段顺序和方向必须与索引完全一致
MongoDB 的 sort() 要走索引加速，不是“差不多就行”，而是字段名、顺序、升降序三者都得严丝合缝。比如你写 db.orders.find().sort({ status: 1, createdAt: -1, priority: 1 })，那索引必须是 { status: 1, createdAt: -1, priority: 1 }——换一个字段位置、改一个方向（哪怕只把 status: 1 写成 status: -1），索引就失效。
常见错误现象：
-
sort({ status: 1, createdAt: -1, priority: 1 })却建了索引{ status: 1, priority: 1, createdAt: -1 }→ 前缀匹配失败，不走索引 -
sort({ status: 1, createdAt: -1 })却建了索引{ status: 1, createdAt: 1 }→ 方向不一致，触发内存排序 - 漏写方向：以为
{ status: 1, createdAt: -1 }可以简写成{ status: 1, createdAt: -1 }（实际没错），但误写成{ status: 1, createdAt: -1, priority: 1 }却省略了priority的方向 → MongoDB 不会自动补1，这个字段在索引里就“不存在”
等值查询字段必须放索引最前面
如果你的查询带 find({ status: "paid" }) 并且 sort({ createdAt: -1, priority: 1 })，最优索引不是只覆盖排序字段，而是把等值字段 status 放最前：{ status: 1, createdAt: -1, priority: 1 }。这样既能过滤，又能排序，一步到位。
为什么不能反过来？
-
{ createdAt: -1, priority: 1 }索引对status过滤无效 → 查询阶段全表扫 -
{ status: 1, priority: 1, createdAt: -1 }表面字段全了，但排序字段顺序错 →createdAt不在排序连续前缀上，无法用于sort() - 范围查询（如
{ amount: { $gte: 100 } }）一旦出现，它之后的字段就失去排序能力 → 所以范围字段要放在等值字段之后、排序字段之前，或干脆不参与排序字段序列
排序不稳定时用 _id 兜底
即使索引和 sort() 完全匹配，如果多条文档在排序字段上值相同（比如多个 createdAt 相同的订单），MongoDB 返回顺序仍可能波动——因为 B-Tree 索引不保证相等键下的物理顺序。
解决办法是在 sort() 末尾加一个唯一字段，通常是 _id：
db.orders.find({ status: "paid" })
.sort({ status: 1, createdAt: -1, priority: 1, _id: 1 })
对应索引也得同步带上 _id: 1：{ status: 1, createdAt: -1, priority: 1, _id: 1 }。这不是为了加速，而是让结果可重现——尤其对分页、前端列表渲染这类场景很关键。
验证索引是否真被用了
别光看命令执行成功，要用 explain("executionStats") 确认：
-
stage是IXSCAN（不是COLLSCAN或SORT） -
totalDocsExamined接近nReturned（比如 25 条返回，只查了 30 条文档） -
executionStages.stage里没有SORT阶段（有就说明内存排序还在发生）
最容易忽略的一点：开发环境数据少，sort() 看似快，但一上生产，几万条数据没走索引就会触发 Executor error during find command: Sort exceeded memory limit —— 这个报错不是代码写错了，是索引没对上。
