MongoDB聚合管道实际处理能力受限于内存（单阶段100MiB）、单文档大小（16MB BSON上限）和阶段数量（最多1000个），需通过allowDiskUse、$project精简、$out落库等方式适配；TB级数据可行但非无条件。
MongoDB 聚合管道本身不直接限制「数据集总大小」，而是通过三个硬性约束间接决定它能实际处理多大的数据：内存、单文档大小、阶段数量。只要绕过或适配这些限制，理论上可以处理 TB 级分片集合——但不是无条件的。
单个聚合阶段内存不能超 100 MiB
每个管道阶段（如 $group、$sort、$bucketAuto）默认最多使用 100 MiB RAM。一旦该阶段内部缓存的数据（比如 $group 的中间分组结果）超过此值，就会报错：Exceeded memory limit for $group, default max is 100 MiB。
- 解决办法是显式传
{ allowDiskUse: true }，让 MongoDB 把临时数据写到磁盘（注意：$graphLookup和$group中用$addToSet/$push的场景不支持此选项） - MongoDB 6.0+ 可设全局参数
allowDiskUseByDefault: true，避免每个查询都手动加 -
$sort阶段若没走索引，必须把所有待排序文档加载进内存；这时加$limit在$sort后能显著降低内存压力
输出文档不能超 16 MB BSON 限制
聚合最终返回的每个文档（哪怕只有一条）都不能超过 16 MB。常见于：$group 后用 $push 收集大量子文档、$lookup 关联出巨量嵌套数据、或 $project 展开冗余字段。
- 错误信息通常是：
Document exceeds maximum size of 16777216 bytes - 优先用
$project删掉非必要字段，比$limit更治本 - 若必须保留结构化大结果，改用
$out或$merge写入临时集合，再分页读取 - 不要依赖「管道中间文档可超 16 MB」这点来设计逻辑——最终落地时仍要面对这个墙
单个管道最多 1000 个阶段
这不是性能瓶颈，而是语法层面的硬上限。手写管道极少触达，但自动生成管道（比如 ORM 动态拼接、BI 工具导出）可能意外超标。
- 错误提示：
Exceeded maximum number of pipeline stages (1000) - 拆解方式不是「删阶段」，而是把长管道切成多个
aggregate()调用，用临时集合中转（$out+ 新查询） - 注意：
$out和$merge是写操作，需确认权限和业务是否允许修改目标集合
真正卡住大数据集的往往不是总数据量，而是某个阶段的中间状态膨胀——比如未加 $match 过滤就 $unwind 一个万级数组，或没建索引就 $sort 千万级文档。这些细节比“能不能跑”更影响实际成败。
