在MongoDB慢查询排查中，有一个非常典型的场景：查询本身走了索引，但执行计划里却多出一个SORT阶段，日志中出现错误码2500，提示排序超过了内存限制。这类问题的根源往往不在数据量，而在于排序字段的方向与索引定义的方向不匹配，导致数据库只能把结果集全部拉到内存里排序。本文围绕这个错误展开，讲清楚索引方向与排序方向的匹配原理、排查方法和优化手段。
为什么排序方向必须与索引方向一致
MongoDB的索引底层是B树结构，索引条目按照索引定义中各字段的方向有序存放。以一个单字段索引为例，如果索引按age升序创建，那么遍历索引时可以天然得到age从小到大的结果，也可以倒序遍历得到从大到小的结果。所以对于单字段索引，升序和降序在排序能力上是等价的，这一点经常被误解，很多人以为查询里用了降序排序就必须建降序索引，其实单字段情况下无所谓。
但复合索引的情况完全不同。复合索引的排序顺序是先按第一个字段排，第一个字段相同时再按第二个字段的方向排。假设有一个索引 {userId: 1, createdAt: -1}，它在磁盘上是这样组织的：userId从小到大排列，每个userId内部createdAt从新到旧排列。这时如果查询是 sort({userId: 1, createdAt: -1})，索引顺序完全匹配，可以直接顺序扫描返回结果。但如果查询是 sort({userId: 1, createdAt: 1})，即同一个userId内部要求时间从旧到新，索引就无法满足，因为索引里同一个userId的时间是倒着存的，MongoDB只能取出所有符合条件的数据后在内存中重新排序。
还有一个容易忽略的点：如果排序的所有字段方向整体取反，索引同样可以被利用。例如索引 {a: 1, b: -1} 既可以支持 sort({a: 1, b: -1})，也可以支持 sort({a: -1, b: 1})，因为整棵B树倒着遍历即可。但如果只是部分字段方向取反，比如 sort({a: -1, b: -1})，则无法匹配。理解这一点对设计索引方向非常关键。
如何排查2500错误与内存排序问题
当出现错误码2500时，第一步是用explain命令查看查询计划。重点关注winningPlan里是否出现SORT阶段。如果看到FETCH之前夹着一个SORT，说明排序没有走索引。示范如下：
// 查看查询执行计划
db.orders.find({ userId: 1001 }).sort({ createdAt: 1 }).explain("executionStats")
在输出结果中，如果winningPlan包含SORT_STAGE，同时executionStats里有totalDocsExamined远大于nReturned的情况，基本可以确定索引没有覆盖排序。另外还可以关注executionStages下的memLimit和usedMemory字段，当排序数据超过100MB的内存限制时，就会直接抛出错误码2500，查询失败。这个限制由allowDiskUse参数控制，从4.4版本开始可以按查询开启磁盘排序，但磁盘排序的性能非常差，只应作为兜底手段。
排查时还要注意等值查询与排序字段的组合关系。复合索引的一个特性是：等值条件字段可以固定前缀，排序字段可以紧随其后利用索引顺序。例如索引 {status: 1, createdAt: -1}，查询 find({status: "paid"}).sort({createdAt: -1}) 可以完全走索引，因为status是等值匹配，相当于把索引按status切分成多段后，每段内部都是按createdAt降序排列的。但如果status是范围查询，比如 $in 带多个值，排序就可能失效，因为多个范围的段拼在一起并不保证整体有序。
// 匹配的索引设计：等值字段在前，排序字段在后
db.orders.createIndex({ status: 1, createdAt: -1 })
// 不匹配的场景：范围字段导致多段无序
db.orders.find({ createdAt: { $gte: start, $lte: end } }).sort({ userId: 1 })
// 此时排序字段userId无法利用范围索引的顺序
索引设计建议与排序优化实践
针对2500错误，最根本的解决方式是按照查询模式补建正确的索引。ESR原则（等值、排序、范围）是设计复合索引的经典方法：把等值条件字段放在最前，排序字段放在中间，范围过滤字段放最后。这样排序字段在等值前缀内部是有序的，可以避免内存排序。设计前建议先梳理业务中的高频查询组合，一个索引只服务一类排序模式，避免索引数量膨胀影响写入性能。
如果业务同时需要同一组字段的不同排序方向，比如列表页既支持按时间正序又支持倒序，可以考虑建两个方向相反的索引，或者利用单字段索引方向等价的特性简化设计。但要注意，倒序遍历索引在某些分页场景下效率略低，数据量大时建议实测。对于深分页场景，即使排序走了索引，skip过大的翻页也会扫描大量无用数据，推荐改用范围查询方式翻页，即记录上一页最后一条的排序键值，用大于等于条件继续查询。
// 深分页优化：用排序键做游标，代替skip
const lastCursor = "2024-05-01T10:00:00Z"
db.orders.find({
userId: 1001,
createdAt: { $lt: new Date(lastCursor) }
}).sort({ createdAt: -1 }).limit(20)
最后总结几个要点：错误码2500本质是排序数据超过内存上限，而索引方向不匹配是最常见的诱因；单字段索引升序降序等价，复合索引必须严格匹配或整体取反；等值字段固定前缀后排序字段才能借力索引顺序；遇到问题先用explain确认SORT阶段是否存在，再按ESR原则调整索引。把这些原则落实到索引设计里，绝大多数排序超限和慢查询问题都能在源头避免。
MongoDB故障码索引排序SORT阶段内存限制修改时间：2026-09-10 22:09:41