跳转到主内容
趣航编程网 - 趣学编程,启航技术之路!

如何在MongoDB中根据查询结果批量删除文档_结合bulkWrite与delete操作

bulkWrite中deleteMany需写为{deleteMany:{filter:{...}}}操作对象,不可用db.collection.deleteMany()调用;filter为必需文档,不支持空对象{};跨集合删除须用db.adminCommand({bulkWrite:...})并指定ns字段。 bulkWrite 里怎么写 deleteMany 类型的批量删除 直接用
deleteMany
操作对象,不是调用方法。它必须作为
bulkWrite()
参数数组里的一个元素,结构是
{ deleteMany: { filter: { ... } } }
。注意:没有
.deleteMany()
这种链式调用,那是 shell 里独立方法的写法。 常见错误是把 shell 写法照搬进
bulkWrite()
,比如写成
db.collection.deleteMany({...})
—— 这会报
ReferenceError
或语法错误,因为 bulkWrite 不接受执行语句,只接受操作描述对象。
filter
是必需字段,类型为文档(如
{ status: "archived" }
),不支持空对象
{}
(MongoDB 8.0+ 允许但极危险,慎用) 可选加
collation
控制字符串比较行为,例如大小写敏感删除:
{ collation: { locale: "en", strength: 2 } }
不支持
writeConcern
单独设在某个 deleteMany 操作里,得提一层到
bulkWrite()
的第二个参数中 想删多个集合里的文档,还能用 bulkWrite 吗 可以,但得用
db.adminCommand({ bulkWrite: ... })
命令,而不是
db.collection.bulkWrite()
。后者只能操作单个集合;前者通过命名空间(
"db.collection"
字符串)指定目标,支持跨库跨集。 典型场景是清理微服务架构下分散在不同数据库的日志或缓存文档。比如同时删
auth.users
和
audit.events
中 90 天前的数据。 每个操作必须带
ns
字段,值为
"databaseName.collectionName"
deleteMany
操作在 adminCommand 中写法一致,仍是
{ deleteMany: { filter: ... } }
该命令需
admin
数据库权限,普通集合用户权限不够 mongosh 1.10+ 支持
db.bulkWrite()
辅助方法,底层仍发 adminCommand,但更简洁 ordered: false 时 deleteMany 出错会怎样 设
ordered: false
后,某条
deleteMany
操作失败(比如 filter 语法错、权限不足、集合不存在),其余操作照常执行,最终返回结果里
writeErrors
数组会记录具体哪几项失败及原因,
deletedCount
只统计成功项。 go语言参考手册 中文CHM版 Go 是一个开源的编程语言,它能让构造简单、可靠且高效的软件变得容易。本文给大家带来Go参考手册,需要的可以来下载! Go是从2007年末由Robert Griesemer, Rob Pike, Ken Thompson主持开发,后来还加入了Ian Lance Taylor, Russ Cox等人,并最终于2009年11月开源,在2012年早些时候发布了Go 1稳定版本。现在Go的开发已经是完全开放的,并且拥有一个活跃的社区。 Go 语言特色 简洁、快速、安全 并行、有趣、开源 内存管理、v数组安全、编译 下载 这和默认
ordered: true
(遇到第一个错就中断)形成关键区别。线上批量清理任务建议显式设
false
,避免一条误配的 filter 导致整批数据没删干净。 错误信息在
writeErrors[i].errmsg
里,常见如
"ns does not exist"
或
"not authorized on ..."
即使出错,已执行成功的 deleteMany 也不会回滚 —— MongoDB 没有跨操作事务保障 若需原子性,得改用事务包裹多个
deleteMany
,但事务内不能跨库 bulkWrite 删除 vs 传统 deleteMany 性能差多少 单集合、单条件删除时,
bulkWrite([{ deleteMany: { filter: ... } }])
和
db.collection.deleteMany(...)
底层几乎等价,耗时差异可忽略。真正影响性能的是「是否批量混合其他操作」。 比如你要删一批文档,再更新另一批,再插几条 —— 这时 bulkWrite 能省掉 3 次网络往返,实测 QPS 提升 30%~50%。但如果只是纯删,且条件简单,没必要硬套 bulkWrite。 bulkWrite 的额外开销主要在客户端组装操作数组、服务端解析 JSON 结构,对单操作基本无感 真正要注意的是内存:传入上万条 deleteOne 操作会撑爆 mongosh 内存,应分批(如每批 1000 条)调用 MongoDB 6.1+ 对 deleteMany 自动启用
BATCHED_DELETE
阶段优化,bulkWrite 也受益于此 实际删数据前,别跳过
explain("executionStats")
看执行计划 —— 尤其当 filter 涉及未建索引字段时,
executionStats.nReturned
和
nDocsExamined
差距大,说明要扫全表,这时候删之前先确认数据量,避免阻塞。

相关文章