allowdiskuse: true 必须作为 aggregate 的第二个参数传入，否则 mongodb 会忽略它；在分片集群中，该选项需正确传递以使各 shard 启用磁盘暂存，而非仅作用于 mongos。
allowDiskUse: true 必须作为第二个参数传入 aggregate
它不是 pipeline 里的一个阶段，也不是 options 里可有可无的配置项——不放对位置，等于没开。MongoDB 会直接忽略它，继续在内存里硬扛，直到报 Exceeded memory limit for $group。
-
db.collection.aggregate(pipeline, { allowDiskUse: true })✅ 正确：第二个参数是独立 options 对象 -
db.collection.aggregate([ { $match: ... }, { $group: ... }, { allowDiskUse: true } ])❌ 错误：把它塞进 pipeline 数组，MongoDB 当成无效 stage 处理 - Node.js 驱动中写成
collection.aggregate(pipeline).allowDiskUse(true)（旧链式调用）在分片集群上无效，因为 mongos 不会把该设置透传到 shards；必须用collection.aggregate(pipeline, { allowDiskUse: true })
分片集群下 allowDiskUse 不自动下推到 shards
这是最常被误解的一点：开了 allowDiskUse: true，只代表 mongos 允许自己把中间结果写磁盘（极少需要），真正执行 $group 或 $sort 的是各个 shard，而它们默认仍卡死在 100MB 内存上限。
- mongos 不会自动把
{ allowDiskUse: true }转发给每个 shard 的本地聚合调用 - 你也不需要、也不能手动连到每台 shard 上去执行命令
- 正确做法就是：在应用端或 mongo shell 中发起聚合时，**确保这个选项以第二个参数形式传入**——驱动和 mongos 会协同处理，让各 shard 在本地执行子聚合时也启用磁盘暂存
- 验证是否生效：用
explain("executionStats")查看shards数组里每个节点的usedDisk字段是否为true
加了 allowDiskUse 还慢或失败？先看分片键和 $group 是否对齐
allowDiskUse 解决的是“内存爆了崩溃”的问题，不是“慢”的万能解。如果 $group 的 _id 和分片键完全无关（比如按 user_id 分片，却按 order_date 分组），mongos 就没法下推分组逻辑，只能把所有匹配文档拉到自己内存里归并——这时 allowDiskUse 对 mongos 无效（它不支持磁盘归并），查询大概率 OOM 或超时。
- 优先让
$group的_id包含分片键前缀，例如分片键是{ region: 1, user_id: 1 }，就按{ region: "$region" }分组 - 避免在 $group 前用
$unwind，尤其当 unwind 字段和分片键无关时，极易触发全量广播 - 用
explain("executionStats")观察各 shard 的nReturned和totalDocsExamined：如果某个 shard 返回几百万文档，而其他 shard 几乎为 0，说明分组没下推成功
allowDiskUse 不是性能优化，而是防崩兜底机制
它让聚合不至于因内存超限直接失败，但落盘本身比纯内存操作慢一个数量级。真要提速，得靠前置 $match、合理索引、字段投影和阶段重排。
-
$match越早越好，最好能命中复合索引（遵循 ESR 顺序：等值 → 排序 → 范围） -
$project放在 pipeline 中间减少传输体积，虽然 MongoDB 会自动优化部分投影，但显式声明仍有助于调试和语义清晰 -
$limit要尽可能往前放，尤其在$sort后、$group前，否则排序阶段仍要处理全部数据 - 注意：4.4+ 才支持
$push内嵌$sort，6.0 没问题，但别在 4.2 集群上试；且$push: { $each: ..., $sort: ... }的$each必须是数组，哪怕只推一个字段
