deleteMany 更适合删冗余数据，因其是 MongoDB 4.0+ 标准方法，返回删除数、支持事务，而 remove 已废弃；它支持原子批量删除，避免循环单删的性能与一致性风险。
deleteMany 为什么比 remove 更适合删冗余数据
deleteMany 是 MongoDB 4.0+ 的标准批量删除方法，明确返回被删文档数，且在事务中可安全使用；而 remove 已在 4.4+ 中被标记为废弃，部分驱动（如 Node.js 4.13+）调用它会触发警告甚至报错。
冗余数据往往满足“多条匹配、需原子判断”的条件，比如重复的用户邮箱、过期日志、测试环境残留记录——这类场景下，deleteMany 的过滤表达式能直接嵌套逻辑操作符，避免应用层循环 + 单条 deleteOne 带来的性能和一致性风险。
用 $and / $or / $not 组合条件时的常见坑
MongoDB 的查询条件默认是“与”关系，但显式写 $and 有时反而出错：它要求每个子条件必须是独立对象，不能和字段名并列。例如想删掉 “status 为 draft 且 created_at 早于 2022-01-01” 的文档，下面写法会报错：
db.posts.deleteMany({ status: "draft", created_at: { $lt: ISODate("2022-01-01") } }) // ✅ 正确
而这样写会失败：
db.posts.deleteMany({ $and: [{ status: "draft" }, { created_at: { $lt: ISODate("2022-01-01") } }] }) // ❌ 多余且易漏字段
- 只在需要“同一字段多条件”或“不同字段间逻辑分支”时才用
$or或$not，比如删掉 “status 是 draft 或 temp，但不包含 tag: 'keep'” 的文档 -
$not必须包裹完整操作符，不能直接写{ tags: { $not: "keep" } }，正确是{ tags: { $not: { $eq: "keep" } } } - 所有日期比较务必用
ISODate()或合法字符串（如"2022-01-01T00:00:00Z"），传 JSDate对象在 shell 外可能被序列化失败
删前必做：用 countDocuments 验证条件是否精准
执行 deleteMany 前不验证，等于闭眼按回车。尤其当条件含 $regex、$in 数组或嵌套字段时，很容易误删。
正确做法是先跑一遍等价的统计：
db.posts.countDocuments({ status: "draft", "metadata.test": true })
如果返回 0，说明条件没命中任何文档；如果返回值远超预期，立刻停手检查字段路径和值类型（比如字符串 "123" 和数字 123 不匹配）。
- 不要用
find().length替代countDocuments，前者会拉取全部数据再计数，大集合直接 OOM - 对分片集群，
countDocuments可能比实际慢，但仍是唯一可靠方式；estimatedDocumentCount不支持过滤器，纯属无效替代 - 若要删的文档带 TTL 索引，确认你不是在跟
mongod自动清理抢跑——查db.runCommand({ collStats: "posts" })看indexDetails里有没有expireAfterSeconds
真正安全的删除流程：带写关注 + 限制数量 + 日志留痕
生产环境删数据，核心不是“怎么删”，而是“删错了能不能捞”。单靠 deleteMany 不够，得加三层保险：
- 用
{ writeConcern: { w: "majority", j: true } }确保多数节点落盘，避免主从切换丢操作 - 加
limit参数做灰度（虽然deleteMany本身不支持 limit，但可用find().limit(n).forEach(...)模拟，或先find导出 ID 再分批deleteMany({ _id: { $in: [...] } })） - 把最终执行的命令、匹配数、时间戳记进运维日志，例如：
db.posts.deleteMany({ status: "draft", updated_at: { $lt: ISODate("2022-01-01") } }, { writeConcern: { w: "majority" } })
最常被忽略的一点：删除操作不会触发 change stream，所以依赖它的下游服务（如搜索同步、缓存失效）必须手动补事件——别指望删完就自动更新。
