MongoDB的聚合管道功能强大，可以完成数据的过滤、分组、变换等复杂操作，但不少开发者在使用过程中会产生一个疑问：聚合管道里有没有类似$delete的删除阶段？能不能在聚合执行的过程中直接把满足条件的数据从集合里删掉？这个问题的答案有点绕，MongoDB官方并没有提供名为$delete的聚合阶段，但可以通过$merge、$out等写阶段配合特定策略，间接实现聚合后删除数据的效果。本文就来详细拆解这个问题，并给出几个可直接落地的实现方案。
为什么聚合管道中没有$delete阶段
首先要明确一个事实：截至目前的所有MongoDB版本，聚合管道提供的写阶段只有$out和$merge两个，它们都只能写入数据，不能删除数据。官方之所以这样设计，与聚合管道的定位有关。聚合管道本质上是一个数据流处理模型，文档从上游阶段流向下游阶段，每个阶段对文档做变换。删除操作是一个破坏性的写动作，一旦插入到管道中间，后续阶段的输入数据就可能出现不一致，恢复成本极高。
更实际的原因在于事务与幂等性。聚合管道在执行时并不保证整体原子性（除了个别场景下的内部优化），如果允许在管道中间删除文档，一旦管道中途失败，已删除的数据无法回滚，这在生产环境中是不可接受的风险。因此官方把删除操作严格限制在deleteMany、deleteOne、findOneAndDelete这类命令中，这些命令可以纳入事务，行为可控。
不过需求是真实存在的。比如日志归档场景，我们需要把过期的日志聚合汇总后写入归档集合，再把源集合里的对应数据清掉。这类需求虽然不能直接用$delete，但完全可以用组合方案解决。
用$merge实现聚合后的条件性清理
$merge是MongoDB 4.2引入的写阶段，它可以把聚合结果合并到指定集合中。虽然它不能直接删除文档，但它的whenMatched选项支持replace、merge、keepExisting、fail以及自定义管道更新，配合whenNotMatched的insert、discard等选项，可以实现很多带条件的数据重写逻辑。
一个典型技巧是软删除：通过$merge给匹配的文档打上删除标记，再用一次deleteMany统一清理。示例如下：
// 第一步：聚合找出需要"删除"的数据，打上标记后合并回原集合
db.orders.aggregate([
{ $match: { status: "expired", createdAt: { $lt: ISODate("2024-01-01") } } },
{ $addFields: { deleted: true, deletedAt: new Date() } },
{ $merge: { into: "orders", on: "_id", whenMatched: "replace" } }
]);
// 第二步：基于标记执行真正的物理删除
db.orders.deleteMany({ deleted: true });
这种两步走的方式的好处是可控性强，中间可以插入业务校验，甚至可以把第一步的结果先写到备份集合留档，确认无误后再执行删除。缺点是多了一次写操作，对大集合来说需要评估磁盘IO压力。另外$merge要求on字段必须有唯一索引，_id天然满足，但如果用其他字段作为匹配键，记得提前建索引，否则会直接报错。
用$out全量重写集合模拟删除效果
另一种思路是反转逻辑：不删除不要的数据，而是把要保留的数据挑出来重写整个集合。$out阶段会先用聚合结果完全替换目标集合的内容，如果目标集合就是原集合本身，就相当于把不满足条件的文档全部清除了。
// 保留全部有效订单，过滤掉已完成超过一年的订单
db.orders.aggregate([
{ $match: {
$or: [
{ status: { $ne: "completed" } },
{ completedAt: { $gte: new Date(Date.now() - 365 * 24 * 3600 * 1000) } }
]
}},
{ $out: "orders" }
]);
这个方案的优点是一次聚合就完成清理，逻辑集中，不需要额外的标记字段。但风险也很明显：$out是先写临时集合再原子性替换，过程中原集合不可写（对于分片集合甚至不支持$out到自身），而且一旦聚合条件写错，数据就真的没了，操作前务必做好备份。它更适合定时批处理任务，比如每天凌晨清理过期数据，而不适合在线业务高峰期执行。
还需要注意版本差异，$out在分片环境下只能写入不存在的集合或空集合，遇到分片场景建议改用$merge加whenMatched: "replace"的组合，或者干脆回到deleteMany的路线。
删除操作的性能与安全注意事项
无论采用哪种方案，批量删除都绕不开性能问题。deleteMany在删除大量文档时会产生大量写锁和oplog记录，如果一条语句删除的数据量超过几十万条，建议分批执行。可以用limit配合循环的方式控制每批的删除量：
// 分批删除，每批最多 5000 条，避免长事务和大量锁
while (true) {
const ids = db.orders.find(
{ deleted: true },
{ _id: 1 }
).limit(5000).toArray().map(d => d._id);
if (ids.length === 0) break;
db.orders.deleteMany({ _id: { $in: ids } });
}
其次要关注索引命中情况。删除条件字段如果没有索引，MongoDB会做全表扫描，在大集合上代价极高。执行前可以用explain确认删除走的索引计划。对于按时间清理的场景，给时间字段建索引基本是必选项。
最后是安全兜底。生产环境执行删除前，建议先把待删除数据导出到备份集合，例如用$merge写入一个orders_trash集合，保留几天确认无影响后再彻底清除。如果数据库开启了副本集，还可以利用oplog窗口做时点恢复，但这个窗口有限，不能作为唯一保障手段。总之，MongoDB虽然没有$delete聚合阶段，但通过$merge标记、$out重写、分批删除这三板斧，足以覆盖绝大多数聚合加删除的组合需求，关键是根据数据量、业务容忍度和执行时机选择合适的方案，并始终留好退路。
MongoDB聚合管道$delete数据删除修改时间：2026-09-04 11:08:44