MongoDB嵌套数组内$lookup的性能优化与最佳实践问询

你的当前聚合查询在小规模数据下能正常工作，但面对2000万客户、每个客户平均50条订单的量级，这个方案的资源消耗会高到无法承受——核心问题出在$unwind和$group这两步：

• $unwind: "$orders"会把每个客户的50条订单拆成50个独立文档，2000万客户瞬间会膨胀出10亿级别的中间文档，这会占用巨量内存、CPU和IO资源；
• 后续的$group又要把这些拆分的文档重新合并回去，进一步加剧资源消耗，完全不适合每分钟执行一次的高频场景。

结合你的场景特点（articles集合仅80条数据，极小且稳定），我们可以用无文档膨胀的数组关联方案，彻底规避拆分-合并的开销：

优化后的聚合查询 #

db.customers.aggregate([
  // 匹配目标客户（和原逻辑一致）
  { $match: { "_id": 1 } },
  // 一次性获取所有商品数据（仅80条，几乎无开销）
  {
    $lookup: {
      from: "articles",
      pipeline: [], // 空管道表示获取整个articles集合
      as: "articlesList"
    }
  },
  // 遍历orders数组，合并商品名称并清理临时字段
  {
    $addFields: {
      orders: {
        $map: {
          input: "$orders",
          as: "order",
          in: {
            // 合并原始订单数据和匹配到的商品名称
            $mergeObjects: [
              "$$order",
              {
                name: {
                  $getField: {
                    field: "name",
                    input: {
                      // 从articlesList中筛选出匹配当前订单的商品
                      $first: {
                        $filter: {
                          input: "$articlesList",
                          cond: { $eq: ["$$this._id", "$$order.articleId"] }
                        }
                      }
                    }
                  }
                }
              }
            ]
          }
        }
      },
      // 移除临时的商品列表字段
      articlesList: "$$REMOVE"
    }
  }
])

为什么这个方案更高效？ #

• 无文档膨胀：全程只处理$match匹配到的客户文档（如果是单个客户就是1条），没有拆分-合并的中间步骤，内存占用可以忽略不计；
• 利用小集合优势：一次性获取80条商品数据，比多次$lookup关联的开销低得多；
• 数组操作更轻量：$map+$filter都是内存级别的数组计算，性能远高于$unwind+$group的文档级操作。

更进一步的优化建议（如果业务允许） #

因为articles集合数据量极小且大概率不会频繁变更，你可以把商品数据缓存到应用层：

1. 启动时从articles集合加载所有数据，生成一个{_id: name}的映射字典；
2. 每次查询customers集合时，只需要获取原始文档，在应用层遍历orders数组，用映射字典给每个订单填充name字段。

这种方式能彻底把数据库的聚合操作转移到应用层，数据库只需要做简单的单集合查询，性能会再上一个台阶，完全适配每分钟一次的高频执行需求。

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