MongoDB 在 find 查询和聚合管道中执行排序时，如果无法依靠索引直接返回有序结果，就会进入内存排序阶段。官方为这个阶段设定了 32MB 的缓冲区上限，换算成字节是 33554432。当一条排序操作需要暂存的数据量超过这个阈值时，MongoDB 不会自动降级为磁盘排序，而是直接返回错误码 1310，并中断当前操作。这类故障往往不是因为机器内存不够，而是查询没有命中有效的排序索引。
一、错误码 1310 的触发机制
MongoDB 的查询执行器在处理 sort 时有两条路径。第一条路径是索引排序，即查询计划选择了一个与排序字段顺序匹配的索引，扫描索引时天然按目标顺序返回文档，不需要额外的排序缓冲区。第二条路径是阻塞式内存排序，通常称为 blocking sort，执行器必须把匹配的所有文档读入内存临时区域，再按照排序键重新排列。
内存排序并非完全不可用。对于小集合或者高选择性的查询，32MB 缓冲区足够覆盖结果集，性能损耗可以接受。但一旦涉及低选择性条件、深分页、大结果集或排序字段没有索引，缓冲区就会迅速膨胀。默认上限是 32MB，而不是全局内存的固定占比。每个排序操作独立计算，也就是说一个连接上的多条排序会分别占用各自的内存限制。
错误信息中常见的文本是 Sort exceeded memory limit of 33554432 bytes, but did not opt in to external sorting。它表达得很明确：排序超过了内存上限，但查询没有选择外部排序（即磁盘临时文件）。解决办法可以是显式允许磁盘排序，也可以从索引层面消除内存排序。
二、如何用 explain 确认排序是否走了内存
在讨论解决方案之前，应该先确认当前查询的真实执行计划。MongoDB 的 explain 方法可以显示 winningPlan。我们可以关注其中的 stage 类型。如果出现 SORT 阶段，说明查询需要额外排序。如果排序由索引直接提供，通常会出现 IXSCAN 并且该阶段的 sortPattern 与排序字段一致。
下面通过一条示例查询分析。假设订单集合没有为 status 与 createdAt 建立复合索引，执行按状态过滤并按创建时间倒序排序的操作：
db.orders.find({ status: "paid" })
.sort({ createdAt: -1 })
.limit(100)
.explain("executionStats");
在返回的统计信息中，winningPlan 可能包含一个 SORT 阶段，并且在 executionStats 里可以看到 totalKeysExamined 与 totalDocsExamined 的值。更直接的信号是 sort 阶段出现在 FETCH 之后，表示先把文档取出来再排序。这类计划在数据量增长后很容易触发 1310。
如果执行计划里排序阶段消失，取而代之的是 IXSCAN 阶段直接以 sortPattern 形式标注排序方向，说明查询已经通过索引完成排序。执行计划是后续优化的重要依据，不要靠猜来判断。
三、临时方案：允许磁盘排序 allowDiskUse
当故障发生时，最直接的操作是让该查询允许磁盘排序。MongoDB 提供了 allowDiskUse 选项，它可以让超过 32MB 的排序数据写入数据库目录下的临时文件中，从而避免 1310 错误。在 find 游标链式调用中，可以这样设置：
db.orders.find({ status: "paid" })
.sort({ createdAt: -1 })
.allowDiskUse(true)
.limit(100);
在聚合管道中，allowDiskUse 需要传给 aggregate 方法的第二个参数：
db.orders.aggregate(
[
{ $match: { status: "paid" } },
{ $sort: { createdAt: -1 } },
{ $limit: 100 }
],
{ allowDiskUse: true }
);
虽然打开 allowDiskUse 能快速止血，但它并不是一个适合长期依赖的方案。磁盘排序会产生大量随机 I/O，在数据量大时会明显增加查询耗时，并可能拖慢同一实例上的其他请求。尤其是分片集群中，临时文件的写入和清理还会增加磁盘空间压力。很多研发团队为了方便会在代码里全局开启 allowDiskUse，这相当于把 32MB 错误从表面隐藏掉，却让查询延迟和磁盘占用持续上升。
四、根治方案：通过复合索引消除内存排序
更合理的做法是让排序走索引。对于前面示例里的查询，筛选条件是 status，排序字段是 createdAt，可以创建一个复合索引：
db.orders.createIndex({ status: 1, createdAt: -1 });
创建索引后，同样的查询会命中 IXSCAN 并直接按照 createdAt 的索引顺序返回结果。这里有两个容易忽略的细节。第一，索引字段的顺序很重要，等值过滤字段应放在排序字段之前。如果查询条件是范围条件，比如 createdAt 在某个区间内，同时还要按 status 排序，那么索引设计可能要调整为 { createdAt: 1, status: 1 }，但具体要看哪个字段是范围过滤。第二，单字段排序时可以匹配相反方向，例如索引是 { createdAt: -1 }，而查询要求 { createdAt: 1 }，MongoDB 可以反向扫描索引，但多字段混合排序时只有完全一致或完全相反才能利用索引。
为了验证优化效果，可以再次执行 explain，观察 winningPlan 中是否已经不存在独立的 SORT 阶段。典型的优化后的执行计划会先通过 IXSCAN 扫描索引，再通过 FETCH 获取完整文档，且 IXSCAN 阶段带有 sortPattern。如果业务中经常按相同字段组合排序，就应当提前规划复合索引，而不是等报错后再补救。
五、聚合管道中的排序优化与注意事项
聚合管道中的 $sort 同样受 32MB 限制。很多人以为只有 find 会报 1310，实际上聚合阶段也可能因为大量文档经过 $group 或 $project 后进入 $sort 而崩溃。解决思路依然是先减少数据量，再考虑是否开启 allowDiskUse。
例如下面这个聚合会先按用户分组，再按总金额排序。如果订单量很大，分组后的文档数量可能仍然很多，排序阶段容易超限：
db.orders.aggregate([
{ $match: { status: "paid" } },
{ $group: { _id: "$userId", total: { $sum: "$amount" } } },
{ $sort: { total: -1 } }
]);
如果排序失败，可以在 aggregate 的第二个参数中加上 { allowDiskUse: true }。但从性能角度考虑，更值得尝试的是把 $sort 放在 $group 之前，或在 $match 中利用索引先过滤出更小的数据集。聚合优化没有通用模板，需要依据管道阶段的数据流动和索引使用情况逐步调整。
六、生产环境预防与监控
要避免 1310 错误频繁出现，需要从监控和流程两方面入手。开启数据库的慢查询日志后，可以筛选包含 sort 阶段的查询，并结合 explain 观察排序是否使用索引。对于已经上线的查询，应该定期检查 system.profile 或通过 currentOp 命令查看正在执行的排序操作。
还可以在应用开发规范中约定：所有涉及 sort 的查询必须提供对应的复合索引设计说明。对于确实无法使用索引且排序数据量较小的场景，可以局部开启 allowDiskUse，但要明确标注影响范围。对于数据量持续增长的业务，32MB 限制不是严格问题，而是提醒你查询模型可能需要重构，例如改为使用游标分批处理、预聚合或增加缓存。
最后，不要把 32MB 限制理解为无法修改的绝对阈值。虽然没有全局参数直接调高这个值，但可以在某些版本中通过 internalQueryExecMaxBlockingSortBytes 参数进行调整。不过修改内部参数存在风险，官方文档通常不推荐在生产环境随意改动。绝大多数情况下，建立合适的索引才是更可靠的选择。
MongoDB 1310错误排序内存限制allowDiskUse修改时间：2026-08-21 20:20:04