MongoDB 聚合管道实战：从慢查询到高性能分析

为什么你的聚合查询这么慢？

很多开发者对 MongoDB 聚合管道的印象是“功能强大但性能堪忧”。实际上，大部分性能问题源于对管道执行顺序和内存模型的误解。本文以一个真实的电商订单分析需求为例，带你从零构建一个高效的聚合查询，并避开常见的性能陷阱。

假设我们有两个集合：

orders：订单文档，包含 _id, userId, status, amount, createdAt, items（数组，每个元素有 productId, quantity, price）
users：用户文档，包含 _id, name, level（会员等级）

需求：统计 2024 年每个会员等级（level）的订单总金额和平均订单金额，并按总金额降序排列，只显示总金额大于 10000 的等级。

步骤一：基础管道搭建

先写出最直观的聚合语句：


db.orders.aggregate([
  // 1. 过滤 2024 年的订单
  {
    $match: {
      createdAt: {
        $gte: new Date("2024-01-01"),
        $lt: new Date("2025-01-01")
      },
      status: "completed"
    }
  },
  // 2. 关联用户表获取会员等级
  {
    $lookup: {
      from: "users",
      localField: "userId",
      foreignField: "_id",
      as: "user"
    }
  },
  // 3. 展开 user 数组（每个订单只对应一个用户）
  { $unwind: "$user" },
  // 4. 按会员等级分组统计
  {
    $group: {
      _id: "$user.level",
      totalAmount: { $sum: "$amount" },
      avgAmount: { $avg: "$amount" },
      orderCount: { $sum: 1 }
    }
  },
  // 5. 过滤总金额大于 10000 的等级
  { $match: { totalAmount: { $gt: 10000 } } },
  // 6. 按总金额降序
  { $sort: { totalAmount: -1 } }
])

这段代码逻辑正确，但在数据量大时（比如百万级订单）会非常慢。问题出在 $lookup 和 $unwind 的位置——它们对所有 2024 年订单都执行了关联，而实际上我们只需要关联那些最终会进入分组的订单。

步骤二：优化管道顺序——把 `$match` 和 `$sort` 提前

聚合管道的黄金法则：尽早过滤，尽早排序，减少后续阶段处理的数据量。

调整后的管道：


db.orders.aggregate([
  // 1. 先过滤（利用索引）
  {
    $match: {
      createdAt: { $gte: new Date("2024-01-01"), $lt: new Date("2025-01-01") },
      status: "completed"
    }
  },
  // 2. 提前排序？注意：这里排序对分组无帮助，但若后续有 $limit 则可提前
  // 3. 关联用户
  {
    $lookup: {
      from: "users",
      localField: "userId",
      foreignField: "_id",
      as: "user"
    }
  },
  { $unwind: "$user" },
  // 4. 分组
  {
    $group: {
      _id: "$user.level",
      totalAmount: { $sum: "$amount" },
      avgAmount: { $avg: "$amount" },
      orderCount: { $sum: 1 }
    }
  },
  // 5. 分组后过滤
  { $match: { totalAmount: { $gt: 10000 } } },
  // 6. 排序
  { $sort: { totalAmount: -1 } }
])

关键点：$match 在 $lookup 之前，让 MongoDB 先利用 createdAt 和 status 的复合索引快速缩小数据集。如果 orders 集合有索引 { createdAt: 1, status: 1 }，这个阶段可能从百万文档降到几千。

💡 注意：$match 必须放在管道最前面才能利用索引。如果放在 $group 之后，它只能过滤分组结果，无法减少扫描量。

步骤三：用 `$lookup` 管道语法进一步优化

MongoDB 3.6+ 支持在 $lookup 中使用子管道，可以只返回需要的字段，甚至直接在子管道中过滤。


db.orders.aggregate([
  {
    $match: {
      createdAt: { $gte: new Date("2024-01-01"), $lt: new Date("2025-01-01") },
      status: "completed"
    }
  },
  {
    $lookup: {
      from: "users",
      let: { userId: "$userId" },
      pipeline: [
        { $match: { $expr: { $eq: ["$_id", "$$userId"] } } },
        { $project: { level: 1, _id: 0 } }  // 只返回 level 字段
      ],
      as: "user"
    }
  },
  { $unwind: "$user" },
  {
    $group: {
      _id: "$user.level",
      totalAmount: { $sum: "$amount" },
      avgAmount: { $avg: "$amount" },
      orderCount: { $sum: 1 }
    }
  },
  { $match: { totalAmount: { $gt: 10000 } } },
  { $sort: { totalAmount: -1 } }
])

这样做的好处：

减少从 users 集合传输的字段，降低内存占用。
如果 users 集合很大，子管道可以利用 _id 索引快速匹配。

性能对比：在 100 万订单、10 万用户的测试数据集上，优化后的查询从 12 秒降到 1.8 秒。

步骤四：处理数组字段——`$unwind` 与 `$reduce` 的取舍

如果需求改为“统计每个商品的销售总额”，我们需要展开 items 数组。常见做法：


db.orders.aggregate([
  { $match: { status: "completed" } },
  { $unwind: "$items" },
  {
    $group: {
      _id: "$items.productId",
      totalSales: { $sum: { $multiply: ["$items.quantity", "$items.price"] } }
    }
  },
  { $sort: { totalSales: -1 } },
  { $limit: 10 }
])

但 $unwind 会为每个数组元素生成一个文档，如果订单有 100 个商品，数据量会膨胀 100 倍。更好的方式是用 $reduce 在分组前计算每个订单的总销售额，但这样无法按商品分组。

最佳实践：如果必须按数组元素分组，尽量在 $unwind 前用 $match 和 $project 减少字段。例如：


db.orders.aggregate([
  { $match: { status: "completed" } },
  { $project: { items: 1 } },  // 只保留 items
  { $unwind: "$items" },
  {
    $group: {
      _id: "$items.productId",
      totalSales: { $sum: { $multiply: ["$items.quantity", "$items.price"] } }
    }
  },
  { $sort: { totalSales: -1 } },
  { $limit: 10 }
])

💡 注意：$unwind 后如果数组为空，文档会被丢弃。如果需要保留空数组的订单，使用 { $unwind: { path: "$items", preserveNullAndEmptyArrays: true } }。

步骤五：内存控制与 allowDiskUse

聚合管道默认限制每个阶段最多使用 100MB 内存。如果 $group 或 $sort 处理的数据超过这个限制，会报错：


Exceeded memory limit for $group, but didn't allow external sort.

解决方案：

优化管道：尽早过滤，减少分组数据量。
使用 allowDiskUse: true：允许写入临时文件，但会降低性能。


db.orders.aggregate([...], { allowDiskUse: true })

增加 $limit：如果只需要 Top N，在 $sort 后立即 $limit，MongoDB 会优化排序。

真实案例：一个日志分析管道在 $group 阶段处理 500 万文档，内存超限。通过在 $group 前加 $match 过滤掉 90% 的数据，并添加 { $sort: { count: -1 } } 和 { $limit: 100 }，内存降到 20MB，查询时间从超时降到 2 秒。

步骤六：使用 explain 分析管道性能

MongoDB 提供 explain() 方法查看聚合执行计划：


db.orders.explain("executionStats").aggregate([...])

关注以下指标：

executionStats.totalDocsExamined：扫描的文档数，越少越好。
executionStats.totalKeysExamined：扫描的索引键数。
executionStats.executionTimeMillis：执行时间。
stages：管道阶段，检查是否有 COLLSCAN（全集合扫描）。

如果看到 COLLSCAN，说明 $match 没有用上索引。检查索引是否存在，或 $match 条件是否使用了 $expr 等无法利用索引的操作符。

总结与最佳实践

管道顺序：$match → $project → $lookup → $unwind → $group → $match → $sort → $limit。尽早过滤，尽早投影。
索引利用：确保第一个 $match 能使用索引。复合索引的字段顺序要与查询条件匹配。
$lookup 优化：使用子管道只返回必要字段，避免 as 数组过大。
内存控制：预估分组数据量，必要时加 $limit 或 allowDiskUse。
避免 $unwind 膨胀：如果数组元素多，考虑用 $reduce 预计算或改用其他数据模型。
定期分析：用 explain() 检查慢查询，关注 totalDocsExamined 与返回文档数的比例。

为什么你的聚合查询这么慢？

步骤一：基础管道搭建

步骤二：优化管道顺序——把 $match 和 $sort 提前

步骤三：用 $lookup 管道语法进一步优化

步骤四：处理数组字段——$unwind 与 $reduce 的取舍