allowDiskUse没生效最常见的原因是传参位置错误，即误将{allowDiskUse: true}放入pipeline数组而非作为aggregate()方法的第二个参数对象；此外在分片集群中该选项不会自动穿透至各shard，必须显式传入，且需确保磁盘空间、权限及分片键与$group字段对齐。
allowDiskUse没生效，是因为传参位置错了
最常见的情况：把 {allowDiskUse: true} 塞进了 pipeline 数组里，比如写成 [{$group: {...}}, {allowDiskUse: true}] —— 这个对象会被当成一个聚合阶段，MongoDB 直接报语法错误或忽略它。
正确做法是把它作为 aggregate() 方法的**第二个参数对象**，和 pipeline 分开：
db.collection.aggregate([{$group: {_id: "$x", count: {$sum: 1}}}], {allowDiskUse: true})
在驱动里也一样：Node.js 的 collection.aggregate(pipeline, options)、Java 的 AggregationOptions 构造器，都必须走 options 参数通道，不能拼进 pipeline。
分片集群下 allowDiskUse 不穿透到 shard
即使你在 mongos 上加了 {allowDiskUse: true}，各 shard 本地执行子聚合时仍默认禁用磁盘排序/分组——mongos 不会自动把该选项转发下去。
这意味着：哪怕总数据量不大，只要某个 shard 上的局部结果超 100MB（默认值），就会单独报错 Exceeded memory limit for $group。
- 必须确保应用层调用时明确传入
{allowDiskUse: true} - 确认 MongoDB 版本：6.0+ 默认开启
allowDiskUseByDefault，但分片集群仍需显式传参才生效 - 旧版本（如 4.4/5.0）不支持自动 fallback，漏传就必然失败
$group 或 $sort 前没做有效过滤，中间结果早爆了
allowDiskUse 解决的是“内存不够用”，不是“结果太大”。如果 $group 输出的单个文档本身超过 16MB（BSON 限制），或者 $sort 前加载了海量冗余字段，磁盘也救不了。
典型陷阱：
-
$match写在$group后面 → 全量文档先加载进内存再筛 -
$project没精简字段 → 把含图片 Base64、长日志文本的整文档拖进分组 - 分片键和
_id完全无关 → 所有数据被拉到 mongos 归并，allowDiskUse对 mongos 无效（它不支持磁盘归并）
查执行计划：db.collection.explain("executionStats").aggregate([...])，看 shards 里各节点的 totalDocsExamined 是否远大于 nReturned —— 如果是，说明分组根本没下推。
磁盘空间本身不够，或者权限不对
allowDiskUse 需要 MongoDB 进程有写权限的真实磁盘空间。常见盲区：
- 临时目录（通常是
/tmp或dbPath/_tmp）所在分区已满 - Docker 容器没挂载足够 volume，或
tmpfs大小设得太小 - Linux SELinux 或 AppArmor 限制了 mongod 对临时目录的写入
- 某些云厂商 MongoDB 服务（如阿里云、腾讯云）默认禁用磁盘临时文件，需后台开关授权
查日志里有没有类似 Unable to create temp file in /tmp 或 No space left on device 的线索，比盯着报错更直接。
真正卡住人的地方，往往不是要不要开 allowDiskUse，而是它在哪一级生效、对谁生效、以及生效前数据是否已经膨胀到不可收拾。磁盘只是缓兵之计，管道写法和分片设计才是根因。
