超过16MB限制时如何计算MongoDB聚合结果大小

你当前方案失效的核心原因是MongoDB存在单BSON文档*16MB的硬限制，连续5个$lookup会把所有关联集合的匹配结果全拼接到主文档中，当关联数据量较大时，管道阶段输出的单文档体积会直接超过阈值，根本无法执行到后续$bsonSize计算的步骤。

方案1：管道内即时计算+清理大字段（改造成本最低） #

核心思路是每完成一个$lookup关联，立刻计算当前关联生成数组的BSON体积，随后直接删除数组内容，仅保留体积计数，让管道中流转的文档始终保持小体积，从根源上避免触发16MB限制。
改造后的聚合代码示例：

[
  // 匹配目标用户的主文档
  { $match: { user: userId } },
  // 先计算主文档自身的基础大小
  { $set: { mainDocSize: { $bsonSize: '$$ROOT' } } },
  // 第一个关联查询
  {
    $lookup: {
      from: 'anyvalidcollection1',
      localField: 'validlocalfield1',
      foreignField: 'validforeignfield1',
      as: 'alias1'
    }
  },
  // 计算alias1数组大小后立刻删除原数组，不保留原始关联数据
  { $set: { alias1Size: { $bsonSize: '$alias1' } } },
  { $unset: 'alias1' },
  // 后续关联查询全部按「关联→算大小→删原数组」逻辑处理
  {
    $lookup: {
      from: 'anyvalidcollection2',
      localField: 'validlocalfield2',
      foreignField: 'validforeignfield2',
      as: 'alias2'
    }
  },
  { $set: { alias2Size: { $bsonSize: '$alias2' } } },
  { $unset: 'alias2' },
  {
    $lookup: {
      from: 'anyvalidcollection3',
      localField: 'validlocalfield3',
      foreignField: 'validforeignfield3',
      as: 'alias3'
    }
  },
  { $set: { alias3Size: { $bsonSize: '$alias3' } } },
  { $unset: 'alias3' },
  {
    $lookup: {
      from: 'anyvalidcollection4',
      localField: 'validlocalfield4',
      foreignField: 'validforeignfield4',
      as: 'alias4'
    }
  },
  { $set: { alias4Size: { $bsonSize: '$alias4' } } },
  { $unset: 'alias4' },
  {
    $lookup: {
      from: 'anyvalidcollection5',
      localField: 'validlocalfield5',
      foreignField: 'validforeignfield5',
      as: 'alias5'
    }
  },
  { $set: { alias5Size: { $bsonSize: '$alias5' } } },
  { $unset: 'alias5' },
  // 展开file_data数组
  { $unwind: { path: '$file_data', preserveNullAndEmptyArrays: false } },
  // 汇总所有大小
  {
    $group: {
      _id: 'sum',
      totalBsonSize: {
        $sum: {
          $add: ['$mainDocSize', '$alias1Size', '$alias2Size', '$alias3Size', '$alias4Size', '$alias5Size']
        }
      },
      totalFileSize: { $sum: '$file_data.size' }
    }
  }
]

注意：你原代码中$unwind的includeArrayIndex参数传值'0'属于写法错误，该参数需要传入自定义的字段名用来存储数组下标，传'0'会额外生成无意义的冗余字段，不需要索引统计时直接去掉该参数即可。

方案2：分集合独立统计（性能最优，适合超大数据量场景） #

如果单用户关联数据量极大，哪怕单步$lookup都可能触发16MB限制，可以完全放弃跨集合$lookup逻辑，拆分查询独立统计每个集合的体积后手动加总：

• 第一步：主集合匹配user: userId，直接用$bsonSize计算所有匹配主文档的总大小，同时提取所有关联键的值
• 第二步：针对每个关联集合，用提取到的关联键做匹配，直接在对应集合内计算匹配文档的$bsonSize总和
• 第三步：把主集合+所有关联集合的大小统计结果相加，得到最终的总体积

这个方案完全不存在多文档拼接的逻辑，哪怕单用户关联数据达到GB级也能正常运行，而且可以并行查询多个集合，统计速度比多$lookup的管道快很多。

所有MongoDB聚合操作只要涉及将多个文档内容拼接到单条文档的逻辑（比如$lookup生成大数组、$group用$push/$addToSet攒大量数据），都要注意*16MB单文档硬限制，最稳妥的处理方式就是计算完需要的统计值后立刻删除大体积的中间字段，不要让大字段在管道中多阶段流转。

内容的提问来源于stack exchange，提问作者Mr. Twinkle Sharma