报错本质是MongoDB拒绝在内存中执行大排序，必须二选一：优先建覆盖索引实现索引排序，或显式启用allowDiskUse(true)允许磁盘辅助排序；32MB为硬限制（code:96），100MB为带磁盘选项时的默认内存上限。
直接说结论：报错 Sort exceeded memory limit 本质是 MongoDB 拒绝在内存里做“大排序”，你必须二选一——要么让排序走索引（推荐），要么显式允许它用磁盘（应急）。没有第三条路。
为什么 sort() 会爆内存，而加个索引就没事？
MongoDB 只有在能“按索引顺序直接取数据”时，才不加载全量文档进内存。否则它就得把所有匹配文档读出来、放进内存、再排序——这个过程上限很严：
- 32MB 是硬门槛：非索引排序一旦超
33554432字节（约 32MB），直接报错code: 96； - 100MB 是软上限：带
allowDiskUse:true的聚合或 find 查询，默认最多用 100MB 内存（104857600字节），再超才写磁盘； - 索引不是“加速器”，而是“绕过内存排序的通行证”：只要
sort({a: 1, b: -1})能被某个索引完全覆盖（比如{a: 1, b: -1}或{a: 1, b: -1, c: 1}），MongoDB 就不会碰内存排序逻辑。
allowDiskUse:true 怎么加才生效？
它只对特定操作起作用，且语法位置不能错：
-
find().sort().allowDiskUse(true)—— 仅 MongoDB Shell 和部分驱动（如 Node.js 官方驱动）支持，PyMongo 不支持此链式调用； -
aggregate([...], {allowDiskUse: true})—— 全语言通用，PyMongo、Java Driver、Spring Data Mongo 都认这个对象参数； -
db.runCommand({find: "...", sort: {...}, allowDiskUse: true})—— 原生命令方式，适合调试； - 别在
limit()后面加：顺序无关，但allowDiskUse必须作为顶层选项传入，不是游标方法。
建索引时最容易踩的三个坑
索引建了 ≠ 排序就走索引，常见失效场景：
- 查询条件字段没进索引前缀：比如查
{status: "active"}+ 排序{createdAt: -1}，却只建了{createdAt: -1}，MongoDB 无法跳过全表扫描； - 方向不一致：索引是
{a: 1, b: 1}，但排序写成{a: 1, b: -1}，多数版本（尤其 - 用了
$or、$regex、$text等无法高效利用索引的操作，排序被迫回退到内存。
什么时候该用 allowDiskUse，什么时候必须建索引？
看场景定，不是越快越好：
- 临时导出、后台批处理、一次性分析：开
allowDiskUse:true最省事，但注意磁盘 I/O 和临时文件路径空间（默认/tmp）； - 线上接口、高频查询、分页列表：必须建索引，否则每次请求都刷磁盘，延迟抖动大，还可能拖垮 IO；
- 复合排序（如
sort({cat: 1, score: -1, _id: -1})）：优先建对应顺序的复合索引，比开磁盘更稳；_id降序要小心，某些老版本对_id的排序优化有限。
真正难的不是加参数或建索引，而是确认当前查询是否真的走了索引——务必用 explain("executionStats") 看 stage 是 SORT 还是 IXSCAN，以及 totalDocsExamined 是否等于 nReturned。没验证就上线，和没改一样。
