如何优化MongoDB多集合关联的aggregate聚合查询？

1. 前置管道阶段优化 #

• 首步$match必须命中索引：给$match用到的所有过滤字段创建复合索引，如有排序需求可将排序字段追加到复合索引末尾，尽可能在第一步就过滤掉无效数据，大幅缩小后续管道处理的文档基数，这是优先级最高的优化手段。
• 首步$project只保留必要字段：剔除所有后续管道用不到的字段，尤其是大体积的长文本、嵌套数组字段，降低单文档内存占用和管道传输开销。

2. $lookup 关联环节优化 #

• 被关联集合的关联键必须加索引：集合B、C、D的$lookup对应关联字段需创建独立索引，如果关联键是集合默认的_id则无需额外创建，否则$lookup每次关联都会触发被关联集合的全表扫描，10w级数据下耗时会提升数十倍。
• 用带pipeline的$lookup减少冗余数据拉取：不要直接拉取整个关联文档到当前管道再处理，可在关联阶段就完成被关联集合的过滤、字段裁剪，参考写法：

{
  $lookup: {
    from: "集合B名称",
    localField: "集合A的关联键",
    foreignField: "集合B的关联键",
    // 关联阶段直接过滤、裁剪数据
    pipeline: [
      {$match: {集合B的过滤条件}},
      {$project: {需要返回的字段: 1, _id: 0}}
    ],
    as: "关联结果字段名"
  }
}

• 调整关联顺序：优先关联数据量更小、过滤后结果更少的集合，缩小中间数据体积后再关联大数据量集合。

3. 中间管道逻辑优化 #

• 避免无效的$unwind操作：如果$unwind展开数组后马上就要通过$group合并，优先用$filter、$arrayElemAt等数组操作符直接处理数组，省去展开再合并的计算开销。
• 过滤逻辑尽量前置：把第二个$match阶段尽量提前到$group之前，能过滤多少数据就过滤多少，减少$group的计算量。
• 简化$group计算逻辑：$group阶段仅计算必要的聚合指标，冗余的字段拼接、格式转换等操作可以放到聚合结束后的业务代码层面处理。

4. 执行层面优化 #

• 验证索引命中情况：给聚合语句加上explain("executionStats")执行，查看返回结果中各阶段是否命中预期索引，排查存在全表扫描的环节做针对性优化。
• 开启磁盘使用权限：如果聚合中间结果超过MongoDB默认的100MB内存限制，会触发低速交换甚至报错，可在聚合语句末尾添加{allowDiskUse: true}参数提升大聚合任务的执行稳定性。
• 离线查询优先做预聚合：如果该查询是定期执行的非实时需求，可以编写定时任务提前把关联结果写入专用的汇总集合，业务侧直接查询汇总集合即可，无需每次实时关联4个10w级集合。

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