sort()触发内存超限是因为未命中索引导致全量数据在内存排序，必须按查询+排序字段最左前缀创建匹配索引，并用explain验证IXSCAN无SORT节点。
为什么 sort() 会触发 Exceeded memory limit for $sort？
因为 MongoDB 默认在内存中完成排序，当待排序文档量大、字段长度高（比如长文本、嵌套对象），或未命中索引时，$sort 阶段会把所有匹配结果加载进 RAM。一旦超过默认的 100MB 内存限制（allowDiskUse: false 时），就直接报错。
这不是数据量“太大”的问题，而是“没走索引排序”导致的资源误用。即使只查 10 万条，若 sort({ createdAt: -1 }) 没对应索引，照样爆内存。
- 必须确保
sort()字段和find()查询条件共同构成**最左前缀匹配**的复合索引 - 单字段排序也需建单字段索引，不能依赖_id 或其他无关索引
-
skip()+limit()不减少排序内存开销——MongoDB 仍要先排完再跳过
如何创建能支撑排序的索引？
索引字段顺序必须严格匹配 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 }（createdAt和amount顺序与 sort 不一致）
验证是否命中：执行 explain("executionStats")，检查 executionStats.executionStages.stage 是否为 IXSCAN，且 executionStats.executionStages.inputStage.stage 不存在 SORT 节点。
什么时候必须加 allowDiskUse: true？
仅当排序无法完全由索引覆盖时才启用。比如多字段排序中部分字段无索引、或排序方向混用（{ a: 1, b: -1 } 但索引是 { a: 1, b: 1 }），MongoDB 会退化为内存+磁盘联合排序。
- 开启后，临时文件写入
/tmp（Linux）或系统临时目录，IO 成为瓶颈 - 必须配合
limit()使用，否则磁盘空间可能耗尽 - 不解决根本问题——只是把内存溢出换成磁盘 IO 延迟，应优先优化索引
示例写法：db.orders.find({ status: "shipped" }).sort({ createdAt: -1 }).allowDiskUse(true).limit(50)
聚合管道中的 $sort 怎么避免溢出？
聚合阶段的 $sort 同样受内存限制，且更容易被忽略——因为它不像 find().sort() 那样直观。关键原则不变：让 $sort 尽可能靠近管道开头，并确保其输入已由索引有序提供。
- ❌ 错误顺序：
db.orders.aggregate([ { $match: { status: "shipped" } }, { $addFields: { ... } }, { $sort: { createdAt: -1 } } ])——$addFields破坏索引顺序，强制重排 - ✅ 正确顺序：
db.orders.aggregate([ { $sort: { createdAt: -1 } }, { $match: { status: "shipped" } }, { $limit: 50 } ])—— 利用createdAt索引扫描，再过滤，再截断 - 注意：$sort 在 $match 前，不代表跳过查询条件；MongoDB 会下推 $match 到索引扫描层（只要字段在索引中）
复杂聚合中，宁可拆成两次查询，也不要让 $sort 处理中间计算结果。
真正卡住人的往往不是“要不要建索引”，而是索引字段顺序和查询/排序组合之间的微妙对齐。一个 createdAt_-1 索引，在 find({ userId: 123 }).sort({ createdAt: -1 }) 中有效，在 find({}).sort({ createdAt: -1, status: 1 }) 中就彻底失效——这种细节，explain 一眼就能验出来，但容易被跳过。
