在 MongoDB 中，如果只依赖 find 查询，通常只能完成简单的条件过滤和字段投影。一旦遇到分组统计、多表关联、数据变换等需求，聚合管道就会成为核心工具。$aggregate 是 MongoDB 提供的底层聚合命令，用户通过它提交一个由多个处理阶段组成的数组，让数据库依次对文档流进行筛选、分组、排序和投影等操作。借助管道模型，原本需要多次查询或客户端代码才能完成的逻辑，可以用一条命令表达清楚，并且由数据库引擎高效执行。
在 shell 中，我们更常用 db.collection.aggregate(pipeline, options) 方法，它实际上是对 $aggregate 命令的封装。理解 $aggregate 的底层语法和执行机制，有助于更好地编写管道、分析性能问题。接下来从命令结构、常用阶段、优化建议和与 MapReduce 的对比几个角度展开。
$aggregate 命令的基本语法与执行模型
$aggregate 命令的完整形式可以通过 db.runCommand 调用。它的核心参数包括 aggregate 指定集合名或视图名，pipeline 指定阶段数组，cursor 控制结果集返回方式，allowDiskUse 决定是否允许使用磁盘暂存数据。一个典型的命令调用如下：
db.runCommand({
aggregate: "orders",
pipeline: [
{ $match: { status: "A" } },
{ $group: { _id: "$cust_id", total: { $sum: "$amount" } } }
],
cursor: { batchSize: 100 }
})
上述命令首先用 $match 过滤出状态为 A 的订单，然后按照客户编号 cust_id 分组，并对金额字段求和。管道中的每个元素就是一个阶段，数据像流水一样从一个阶段进入下一个阶段。与 db.collection.aggregate() 方法相比，db.runCommand 形式更接近命令本身的定义，适合在驱动程序中显式传参，而 shell 方法则更简短。
执行模型方面，MongoDB 会尽量以流式方式处理管道，但某些阶段（如 $group 和 $sort）需要收集完整输入后才能输出结果，这类阶段被称为阻塞型阶段。如果数据量超过内存限制，就需要设置 allowDiskUse: true，让临时数据写入磁盘。理解这一点对后续性能优化非常关键。
聚合管道中的所有阶段名称和运算符都以美元符号开头，例如 $match、$sum、$avg。这种命名方式与更新操作符一致，但语义不同。管道运算符作用于文档流，表达式可以引用字段名，引用时需要在字段名前加美元符号，例如 "$amount" 表示读取当前文档的 amount 字段。
高频管道阶段与完整示例
实际开发中，使用频率最高的阶段包括 $match、$group、$project、$sort、$limit 和 $unwind。$match 相当于 find 的过滤条件；$group 执行分组聚合，配合 $sum、$avg、$max、$min 等累加器；$project 负责字段选择或派生新字段；$sort 与 $limit 控制排序和条数；$unwind 则将数组字段拆分为多条文档，方便进一步分析。
下面以一个电商订单集合为例，假设文档结构包含订单号、客户编号、状态、金额和下单时间。我们需要统计每位客户在已完成订单中的总消费，并筛选出消费超过 1000 元的客户，最后按消费额降序排列。完整管道如下：
db.orders.aggregate([
{ $match: { status: "COMPLETED" } },
{
$group: {
_id: "$cust_id",
totalSpent: { $sum: "$amount" },
orderCount: { $sum: 1 }
}
},
{ $match: { totalSpent: { $gt: 1000 } } },
{ $sort: { totalSpent: -1 } },
{ $project: { _id: 0, cust_id: "$_id", totalSpent: 1, orderCount: 1 } }
])
这条管道首先过滤掉未完成订单，接着按客户编号分组并计算总金额与订单数，再对生成的结果做第二次 $match，只保留总消费超过 1000 的客户。最后按总消费降序排列，并通过 $project 输出所需的字段结构。可以看到，$match 可以出现在管道前部，也可以在中部对新生成的字段进行过滤，这比在客户端代码中循环判断更简洁。
如果需要关联其他集合的数据，可以使用 $lookup。例如订单集合只存商品编号，商品明细在 products 集合，可以通过 $lookup 将商品信息关联到订单文档，再结合 $unwind 摊平数组进行分组统计。典型写法如下：
db.orders.aggregate([
{
$lookup: {
from: "products",
localField: "product_id",
foreignField: "_id",
as: "product_info"
}
},
{ $unwind: "$product_info" },
{
$group: {
_id: "$product_info.category",
totalSales: { $sum: "$amount" }
}
}
])
该示例先通过 $lookup 把商品详情以数组形式嵌入 product_info 字段，然后 $unwind 将每个商品拆成独立文档，最后按商品分类汇总销售额。需要注意的是，$lookup 会带来额外的读取开销，关联字段上创建索引能显著改善性能。
聚合性能优化与常见误区
聚合管道的性能往往取决于阶段顺序和索引利用情况。最核心的一条原则是：$match 尽量放在管道最前面。这样可以在进入后续高开销阶段之前就大幅减少文档数量。如果 $match 使用了集合上的索引，则过滤效率更高。例如在订单状态字段上建立索引后，前面的示例就能快速定位到已完成订单。
另一个容易被忽视的优化点是字段裁剪。$project 放在管道前部可以提前丢弃不需要的字段，减少后续阶段处理和内存占用。同时，$sort 与 $limit 配合时，如果排序字段有索引，MongoDB 可能只扫描前 N 条文档，从而避免全量排序。对于数据量极大的聚合任务，可以开启 allowDiskUse: true，避免内存不足报错，但磁盘写入会降低速度，因此仍需从管道设计上尽量减少数据体量。
常见误区包括：在 $group 之前没有使用 $match 过滤无关文档，导致全集合扫描；过度使用 $lookup 或多个连续 $lookup，让数据库执行类似 SQL 的多表连接而消耗大量资源；在 $project 中重复计算复杂表达式，增加了每次处理的成本。另一个隐蔽问题是管道嵌套层级过深，使得数据流难以调试，此时可以考虑拆分为多个聚合查询，中间结果写入临时集合，分步执行。
举例来说，下面的写法没有优化，性能较差：
db.orders.aggregate([
{
$group: {
_id: "$cust_id",
totalSpent: { $sum: "$amount" }
}
},
{ $match: { totalSpent: { $gt: 1000 } } }
])
这段管道先对所有文档分组，再过滤分组结果。如果集合包含大量无效订单，会白白消耗内存和计算资源。优化后的写法是在最前面加上 $match: { status: "COMPLETED" }，同时确保状态字段有索引。这样虽然逻辑结果相同，但执行效率会明显提高。
聚合管道与 MapReduce 的对比及选型建议
在 MongoDB 早期版本中，复杂的聚合任务通常依赖 MapReduce。MapReduce 通过 JavaScript 编写 map 和 reduce 函数，再执行合并或最终化函数，能够实现非常灵活的逻辑，但缺点是代码冗长、调试困难，而且 JavaScript 引擎的执行效率远低于原生 C++ 实现的聚合管道。例如同样统计订单总额，MapReduce 需要二三十行代码，而聚合管道只需几个阶段对象。
聚合管道自 MongoDB 2.2 引入以来，经过多个版本增强，已经覆盖了绝大多数统计需求。它使用声明式语法，可读性更强，也更便于索引优化和查询计划分析。相比之下，MapReduce 更适合那些无法用管道运算符表达的复杂自定义逻辑，例如需要多次迭代或依赖外部变量的场景。但即便这样，现代 MongoDB 也提供了 $function 等运算符在管道中嵌入 JavaScript 函数，进一步缩小了必须使用 MapReduce 的范围。
实际选型时，只要需求能够用 $match、$group、$project、$lookup、$unwind 等阶段组合完成，就应优先采用聚合管道。只有在项目遗留代码中已经使用 MapReduce 且运行稳定，或者管道无法轻松表达业务逻辑时，才考虑保留 MapReduce。对于新项目，几乎没有理由再引入 MapReduce 来承担常规聚合任务。
总之，$aggregate 命令是 MongoDB 数据统计的核心入口，掌握管道设计和优化方法，可以显著减少应用层的数据处理压力，同时获得更高的执行效率。建议在实际工作中多使用 explain 查看聚合执行计划，验证优化效果，并定期检视管道是否随着数据增长而出现新的性能瓶颈。
MongoDB聚合管道aggregate命令聚合查询修改时间：2026-10-04 19:20:20