在MongoDB聚合管道中，数组收集操作是分组统计阶段最常用的功能之一。push和addToSet作为两个核心累加器操作符，都能够在$group阶段将多个文档的字段值汇聚成数组，但它们在去重行为、性能表现和适用场景上存在显著差异。理解这些差异对于编写高效且语义正确的聚合查询至关重要。
push操作符的工作原理与典型应用场景
push是聚合管道中最基础的数组累加器，它的行为非常直观：遍历当前分组内的每个文档，提取指定字段的值，然后将其追加到结果数组的末尾。整个过程不执行任何去重判断，所有遇到的值都会被完整保留，包括重复值和null值。这种简单追加的特性使得push在时间复杂度上表现为常数级别，每个文档只需一次追加操作即可完成收集。
保留重复值的特性在很多业务场景中恰恰是所需要的。以电商订单系统为例，一个用户可能有多笔订单经历了相同的状态变更流程，比如多次从pending变为shipped再变为delivered。如果需要完整记录用户所有订单的状态变更轨迹，push能够忠实地收集每一次状态值，不会遗漏任何信息。这种完整记录对于后续的事件序列分析、行为轨迹追踪等场景非常有价值。
push的另一个优势是支持收集整个文档对象。通过将push的目标设为$$ROOT系统变量，可以将分组内的完整文档全部收集到一个数组中。这种用法在需要先分组再对组内文档做进一步复杂处理时非常实用，比如找出每个部门中薪资最高的前N名员工，可以先用push收集所有员工文档，再在后续阶段用$sortArray排序并截取。
// 订单集合中记录了用户ID和订单状态
// 使用push收集每个用户的所有订单状态
db.orders.aggregate([
{
$group: {
_id: "$userId",
allStatuses: { $push: "$status" },
totalOrders: { $sum: 1 }
}
},
{
$sort: { totalOrders: -1 }
}
])
// 假设原始数据：
// { userId: "u001", status: "pending" }
// { userId: "u001", status: "shipped" }
// { userId: "u001", status: "delivered" }
// { userId: "u001", status: "pending" }
//
// 输出结果：
// { _id: "u001", allStatuses: ["pending", "shipped", "delivered", "pending"], totalOrders: 4 }
// 注意数组中保留了两个"pending"，push不做任何去重
上面的示例清晰地展示了push的行为特征。数组allStatuses中包含了该用户所有订单的状态值，重复的pending状态被完整保留。这种完整的记录方式为后续的数据分析提供了原始素材，但也意味着当分组内文档数量庞大时，生成的数组可能会非常庞大。MongoDB对单个BSON文档的大小限制为16MB，因此在使用push收集大量数据时需要特别注意这个边界约束。
addToSet操作符的去重机制与性能特征分析
addToSet在功能上与push类似，都是将值收集到数组中，但关键区别在于addToSet在每次追加前会执行成员检查。具体来说，当addToSet准备将一个新值加入数组时，它会先遍历已有数组元素，逐一比较是否已存在相同的值。如果找到匹配项则跳过本次追加，如果没有找到才执行追加操作。这种机制确保了最终数组中每个元素都是唯一的。
这种去重特性使得addToSet非常适合用于标签聚合、分类汇总等需要唯一值集合的场景。比如在一个内容管理系统中，每篇文章可能被打上多个标签，同一标签可能被不同编辑重复添加。使用addToSet可以轻松获取每篇文章涉及的所有唯一标签列表，无需在应用层再做额外的去重处理，简化了业务逻辑的复杂度。
然而去重检查的代价不容忽视。每次追加操作都需要线性遍历已有数组，这意味着addToSet的整体时间复杂度随着分组内文档数量和数组规模的增长而上升。在极端情况下，如果一个分组内有十万条文档且字段值的唯一性很高，addToSet的性能可能比push差一个数量级以上。因此在大数据量场景下使用addToSet需要谨慎评估。
// 用户标签集合，记录用户被打上的各种标签
// 使用addToSet获取每个用户的唯一标签列表
db.userTags.aggregate([
{
$group: {
_id: "$userId",
uniqueTags: { $addToSet: "$tag" },
tagRecords: { $sum: 1 }
}
}
])
// 假设原始数据：
// { userId: "u001", tag: "sports" }
// { userId: "u001", tag: "music" }
// { userId: "u001", tag: "travel" }
// { userId: "u001", tag: "music" }
// { userId: "u001", tag: "sports" }
//
// 输出结果：
// { _id: "u001", uniqueTags: ["sports", "music", "travel"], tagRecords: 5 }
// 数组中每个标签只出现一次，重复的music和sports被自动去除
从示例中可以看到addToSet的去重效果非常直接。原始数据中music和sports各出现了两次，但最终数组中只保留了一个。需要注意的是，addToSet不保证数组元素的顺序，元素在数组中的位置取决于它第一次被添加的时机以及内部实现细节。如果业务逻辑对顺序有要求，应该在addToSet之后配合$sortArray操作符进行显式排序。
push与addToSet的选型策略与实战优化方案
在实际项目开发中，选择push还是addToSet需要从业务语义和性能两个维度综合考量。从业务语义角度，如果场景明确需要唯一值集合，addToSet是语义更清晰的选择；如果需要保留完整记录或计划在后续阶段自行处理去重逻辑，push更为合适。从性能角度，push的追加操作是O(1)复杂度，而addToSet的去重检查是O(n)复杂度，在大数据量分组时差异会非常明显。
一种值得考虑的优化策略是分步处理：先在$group阶段使用push快速收集所有值，然后在后续的$project阶段使用$reduce配合$setUnion操作符进行批量去重。这种方式的思路是将昂贵的去重操作从逐文档检查转变为一次性批量处理，在某些数据分布特征下能够获得更好的整体性能。特别是当分组内文档数量很大但最终唯一值数量相对较少时，这种策略的优势更加突出。
无论选择哪种收集方式，都需要关注数组大小的控制问题。对于push来说，由于不去重，数组规模与分组内文档数量成正比，很容易突破合理范围。对于addToSet来说，虽然去重机制本身能控制规模，但如果唯一值数量本身就很大，同样面临数组膨胀的问题。在实践中可以通过$slice操作符限制数组长度，或者将聚合结果通过$out写入新集合进行分批处理。
// 优化策略：先push快速收集，后用$reduce批量去重
db.events.aggregate([
{
// 第一步：用push快速收集所有分类，避免addToSet的逐次比较
$group: {
_id: "$userId",
allCategories: { $push: "$category" }
}
},
{
// 第二步：在project阶段批量去重
$project: {
userId: "$_id",
uniqueCategories: {
$reduce: {
input: "$allCategories",
initialValue: [],
in: {
$setUnion: ["$$value", ["$$this"]]
}
}
},
uniqueCount: {
$size: {
$reduce: {
input: "$allCategories",
initialValue: [],
in: { $setUnion: ["$$value", ["$$this"]] }
}
}
}
}
},
{
$sort: { uniqueCount: -1 }
}
])
// 这种分步策略在分组内文档量大但唯一值较少时性能优势明显
// push阶段是纯追加操作，速度极快
// 去重操作集中在一个阶段完成，避免了反复遍历
上面的优化示例展示了分步处理的思路。在$group阶段使用push快速收集所有分类值，避免了addToSet在分组过程中的逐次比较开销。然后在$project阶段利用$reduce和$setUnion进行批量去重。需要注意的是，这种策略并非在所有场景下都优于直接使用addToSet，具体表现取决于数据分布特征，建议在实际数据集上进行对比测试后再做决定。
最后需要强调的是，聚合管道的性能优化不应局限于单个操作符的选择。在分片集群环境中运行聚合操作时，确保$group阶段的分组字段包含分片键或其前缀，可以让MongoDB在各个分片上并行执行部分聚合，大幅减少跨分片的数据传输量。同时合理建立索引，让管道前端的$match和$sort阶段能够利用索引扫描而非全表扫描，这些架构层面的优化往往比单纯在操作符层面做选择带来的收益更加显著。
MongoDB聚合管道pushaddToSet修改时间：2026-08-22 04:07:17