$facet阶段是MongoDB聚合管道中一个非常实用的工具，它允许开发者在单个聚合操作内定义多个独立的子管道，这些子管道会基于相同的输入文档集并行执行，并将各自的输出结果打包到一个文档的不同字段中。相比传统的多次聚合查询，$facet能够显著降低应用与数据库之间的交互次数，尤其适合报表生成、数据看板等需要同时展示多维度统计信息的场景。理解$facet的执行机制和适用边界，对于优化聚合查询性能、减少资源消耗有着直接帮助。
$facet的基本语法与执行模型
$facet是一个聚合管道阶段，可以放置在管道的任意位置，它接收一个文档作为参数，该文档中的每个字段都对应一个子管道。每个子管道本身是一个完整的聚合管道，可以包含$match、$group、$sort、$limit等常见阶段，但不能包含$out、$merge这类会写入持久存储的阶段。语法结构大致如下：
{
$facet: {
"outputField1": [ <stage1>, <stage2>, ... ],
"outputField2": [ <stage1>, <stage2>, ... ]
}
}
从执行模型来看，$facet会先获取上游管道传递下来的所有文档，然后将这些文档同时作为每个子管道的输入。MongoDB聚合引擎在内部会尝试并行运行这些子管道，但这里的“并行”并不意味着每个子管道都会分配到独立的CPU核心，而是指它们在逻辑上可以同时推进，实际并发度受到服务器CPU核数、内存以及WiredTiger存储引擎的读写能力限制。如果子管道中包含需要排序或大量分组累积的操作，MongoDB可能会将一些数据临时写入磁盘，这会进一步影响并行效率。
值得注意的一点是，$facet并不会改变输入文档的原有结构，它只是将每个子管道的输出结果包装成数组，并以字段名作为键放入最终返回的单个文档中。如果某个子管道没有匹配到任何文档，该字段的值会是一个空数组。这种设计使得$facet非常适合在单次请求中返回多种统计结果，例如一个子管道计算总数，另一个子管道计算平均值，再一个子管道返回Top N记录，所有这些结果可以在同一个响应中呈现给前端。
$facet实战：一次查询返回多个统计结果
以一个电商订单集合为例，假设我们有一个名为orders的集合，文档结构包含字段：orderId、customerId、category、amount、orderDate等。需求是：在同一个查询中统计总销售额、按商品类别分组的销售额、平均每笔订单金额以及最近创建的10笔订单。如果不使用$facet，通常需要发起四个独立的聚合查询，而使用$facet可以将其合并为一次查询。
db.orders.aggregate([
{
$facet: {
"totalSales": [
{ $group: { _id: null, total: { $sum: "$amount" } } }
],
"salesByCategory": [
{ $group: { _id: "$category", total: { $sum: "$amount" } } },
{ $sort: { total: -1 } }
],
"averageOrderAmount": [
{ $group: { _id: null, avg: { $avg: "$amount" } } }
],
"recentOrders": [
{ $sort: { orderDate: -1 } },
{ $limit: 10 }
]
}
}
])
执行上述聚合后，返回的结果会是一个文档，包含四个字段：totalSales、salesByCategory、averageOrderAmount、recentOrders。totalSales和averageOrderAmount字段是数组，但每个数组里只有一个元素（因为分组时_id为null），前端可以直接取第一个元素的属性。salesByCategory是一个按总销售额排序的数组，recentOrders则直接返回了最近10个订单的完整文档。这种一次获取多组数据的方式，尤其适合REST API设计，减少客户端发出的HTTP请求数量，也降低了数据库排队等待的可能性。
与多次独立聚合查询相比，$facet的主要优势在于：第一，减少了应用与数据库之间的网络往返次数，这在数据库和应用服务器不在同一网络环境中时效果尤为明显；第二，MongoDB可以复用相同的输入文档快照，避免多次扫描同一批数据。不过需要注意的是，$facet并不是银弹，如果子管道之间需要共享中间结果，比如两个子管道都先执行了相同的$match或$project，那么这些阶段会在每个子管道内部独立执行，并不会自动共享。此时可以考虑将共享阶段放在$facet之前执行，让所有子管道都从过滤后的数据集开始，从而减少重复计算。
$facet的性能特点与使用注意事项
$facet的并行执行会给MongoDB服务器带来额外的内存和CPU压力。每个子管道都会在内存中维护自己的中间状态，例如$group操作需要维护一个哈希表来累计分组值，$sort则可能需要分配缓冲区。如果多个子管道同时进行大数据量的排序或分组，内存占用可能会迅速上升，甚至触发MongoDB的100MB内存限制错误。因此，在设计$facet的子管道时，应尽量避免在子管道内部进行全量排序或大规模分组，如果必须排序，可以先使用$match或$project缩小数据量，或者让排序在$facet之前完成。
另一个限制是$facet的最终输出文档大小不能超过16MB的BSON文档上限。每个子管道的输出数组都会被合并到同一个文档中，如果某个子管道返回了成千上万条记录，整体结果很容易超过限制。在实际使用中，一定要对子管道的结果数量进行控制，例如使用$limit限制返回条数，或者将不需要完整文档详情的子管道改为只返回统计值。此外，$facet的子管道内部不能使用$out、$merge、$facet本身等阶段，但可以使用$match、$group、$sort、$skip、$limit、$project、$unwind等绝大多数阶段，这为灵活组合提供了很大空间。
从索引利用角度来看，$facet内部执行时，每个子管道都会独立尝试使用索引。如果上游阶段已经通过$match使用了合适的索引，那么子管道会在已过滤的文档集上进行操作，通常不需要再依赖索引。但如果$facet出现在管道的起始位置，且子管道中包含$match，那么MongoDB会为每个子管道分别评估索引使用情况，这可能带来多次扫描同一索引的情况。因此，建议尽量在$facet之前放置一个能够显著减少文档数量的$match阶段，这样既能让后续并行计算的数据量变小，也能减少索引扫描次数。
在实际项目中，$facet常常与$bucket、$bucketAuto等分桶阶段结合使用，用于生成区间分布统计；也可以与$lookup配合，在子管道中关联其他集合，实现多表联合统计。由于$facet可以在一次查询中返回多种维度的数据，它在数据可视化后台、管理面板等场景中非常受欢迎。但开发者需要时刻关注每个子管道的执行成本，通过explain()方法检查各子管道的计划，必要时拆分为多个独立的聚合查询以获得更好的调优灵活性。