报错“Exceeded memory limit for $sort”本质是MongoDB未走索引排序，被迫在内存中加载全部匹配文档排序；必须按查询条件+排序字段最左前缀建复合索引，并用explain验证IXSCAN无SORT节点。
为什么sort()会触发“Exceeded memory limit for $sort”
不是数据量太大，而是没走索引排序。MongoDB 默认在内存里完成 $sort，只要匹配文档多、字段长（比如长文本或嵌套对象），或没命中索引，就会把所有结果加载进 RAM。默认限制是 100MB（allowDiskUse: false 时），超了就直接报错。
典型错误信息："Sort exceeded memory limit of 104857600 bytes" 或 "OperationFailed Sort operation used more than the maximum 335544320 bytes of RAM"。哪怕只查 10 万条，sort({ createdAt: -1 }) 没对应索引，照样爆内存。
- skip()+limit() 不减少排序内存开销——MongoDB 仍要先排完再跳过
- 聚合管道里的
$sort同样受限制，且更容易被忽略 - Atlas 免费层（M0）不支持
allowDiskUse: true，开了也无效
怎么建索引才能让sort()真正走索引
必须按“查询条件 + 排序字段”的最左前缀顺序建复合索引。MongoDB 只能利用索引的连续前缀做排序，不能跳过中间字段，也不能反向混用方向。
例如查询：db.orders.find({ status: "shipped", userId: 123 }).sort({ createdAt: -1, amount: 1 })
- ✅ 正确索引：
db.orders.createIndex({ status: 1, userId: 1, createdAt: -1, amount: 1 }) - ❌ 无效索引：
{ createdAt: -1, status: 1 }（排序字段不在最右连续段） - ❌ 无效索引：
{ userId: 1, status: 1, amount: 1, createdAt: -1 }（字段顺序与sort()不一致）
单字段排序也得单独建索引，别指望靠 _id 或其他无关索引顶替。
如何验证索引是否生效
执行 explain("executionStats")，重点看两个地方：
-
executionStats.executionStages.stage必须是IXSCAN（不是SORT或COLLSCAN） -
executionStats.executionStages.inputStage.stage不能存在SORT节点
如果看到 stage: "SORT" 出现在 inputStage 里，说明排序仍在内存里做，索引没被用于排序——要么字段顺序不对，要么查询条件没覆盖索引前缀。
allowDiskUse: true 是救命稻草还是障眼法
它只在聚合管道中有效（db.coll.aggregate([...], { allowDiskUse: true })），且仅对 $sort、$group、$unwind 等阶段启用磁盘临时文件，**不改变 $lookup 加载右表的行为**。
- 必须显式传参，驱动里也要配
options.allowDiskUse = true - MongoDB 版本 ≥ 4.4 才稳定支持，旧版本可能报
"unrecognized field 'allowDiskUse'" - 临时文件写入
/tmp或dbPath/journal/_tmp，需确保 mongod 有读写权限且磁盘空间充足 - 开启后性能取决于磁盘 IO，延迟上升是常态；不配合
limit()容易耗尽磁盘空间
真正容易被忽略的是：索引没建对时，allowDiskUse 只是把内存溢出换成磁盘 IO 延迟，问题根子还在查询设计上。
