MongoDB聚合管道$push内存溢出及BufBuilder 64MB限制问题求助

1. 核心触发原因是MongoDB内部单个BufBuilder缓冲区存在64MB硬编码上限，该限制不受你调整的internalQueryMaxPushBytes、internalQueryMaxBlockingSortMemoryUsageBytes参数控制，且allowDiskUse: true对该场景无效：$group阶段的$push操作会将同分组的所有数据存入单个内存缓冲区做累积，无法拆分落盘，一旦单个分组生成的数组总大小超过64MB就会直接抛出13548错误。
2. 你观察到的异常数据量反差现象，本质是分组基数差异导致：10天时间范围总数据量更大，但你分组用的多字段组合基数更高（比如包含日期维度、设备维度等），每个分组分配到的文档数更少，单个数组大小未触及64MB阈值；单日查询总数据量更低，但存在某一个/几个热点分组key，对应文档数极多，$push生成的单数组超过64MB触发报错。
3. 调高内存限制后查询耗时变长，是因为更大的内存配额会加剧内存碎片、内存调度和GC开销，反而降低了聚合执行效率。

• 【最优方案，适用MongoDB 5.0+】替换现有分组+push+unwind逻辑，改用$setWindowFields窗口函数实现分组筛选：
  按你的多字段分组键做分区，按排序字段排序后生成行号，直接筛选行号在30~180区间的文档，从根源上避免生成全量明细数组，完全不会触发内存溢出问题，执行效率也会大幅提升。
• 【低版本兼容方案】拆分超大分组：
  在原有分组键基础上新增随机取模字段（比如给每个文档加mod: { $mod: ["$id", 10] }），先按原分组键+mod字段做第一层分组$push，筛选每个小分组的前180条数据后再合并做第二层分组二次筛选，避免单个分组的数组过大。
• 【轻量优化方案】缩减$push的字段范围：
  不要$push整行文档，仅保留后续计算需要的字段（比如TRM、统计用数值字段等），大幅降低单数组的字节大小，只要压缩后单数组低于64MB即可规避报错。
• 【兜底方案】拆分聚合任务：
  将大时间范围的查询拆分为多个小时级的小查询分批执行，聚合完每一批的结果后再做二次汇总计算最终指标。

内容的提问来源于stack exchange，提问作者PreuttiP