deletemany会导致写入阻塞，因其在无索引时全表扫描并持集合级排他锁，同时触发磁盘碎片整理与日志刷盘；atlas下磁盘超95%会静默拒绝，返回acknowledged: true但deletedcount: 0。
deleteMany 为什么会导致写入阻塞？
直接调用 deleteMany 删除百万级文档，若过滤字段没建索引，MongoDB 会全表扫描+逐条标记删除，期间集合级锁（W）持续持有，其他写入请求排队等待——尤其在 WiredTiger 引擎下，虽支持文档级并发，但大规模删除仍需升级到集合级排他锁，导致明显延迟甚至超时。
更隐蔽的问题是磁盘压力：大量文档删除会触发后台碎片整理和日志刷盘，Atlas 环境下一旦主节点磁盘利用率突破写入阻塞阈值（默认约95%），deleteMany 会被静默拒绝，只返回 { acknowledged: true, deletedCount: 0 }，不报错也不提示磁盘满。
- 先用
db.collection.explain("executionStats").deleteMany({ yourFilter })看totalDocsExamined是否接近集合总数 - 确认过滤字段已建索引：
db.collection.getIndexes()，缺失则补db.collection.createIndex({ "field": 1 }) - 在 Atlas 控制台检查主节点磁盘使用率，别等
deleteMany返回才去查
分批删除怎么控制 batch size？
不分批硬删，容易触发副本集主从同步延迟、oplog 溢出或客户端超时；batch size 太小（如 100）则网络往返太多，性能反而差；太大（如 50000）又可能卡住单次操作。
实测较稳的区间是 1000–5000，具体看单文档平均大小和集群负载。关键是每次删完主动 sleep，让后台任务喘口气。
- 用
_id分片分批最可靠：先查最小/最大_id，再用{$gt: minId, $lt: maxId}切段 - 避免用时间字段分批时跨时区：统一用
ISODate类型 + UTC 时间戳，别混用datetime.now()和datetime.utcnow() - Python 示例中加
time.sleep(0.1)，Node.js 用await new Promise(r => setTimeout(r, 100))
bulkWrite 能比 deleteMany 更稳吗？
不能。虽然 bulkWrite 支持混合操作和 ordered: false，但它对 delete 类型仍是服务端原子批量执行，底层和 deleteMany 共享同一套锁机制与执行路径。唯一优势是能和其他写操作合并提交，减少网络次数。
真正有用的是它提供的错误粒度：当某一批里部分文档因权限/校验失败被跳过，bulkWrite 会返回详细 writeErrors，而 deleteMany 只告诉你“删了 N 条”，不说明哪几条没删成。
- 仅在需要和 insert/update 混合执行时用
bulkWrite，纯删不用强求换 - 务必设
ordered: false，否则一条失败整批中断 - 删前仍要预估量级：
countDocuments()别省，避免误判为“小批量”而跳过分批
删完为什么查总数还显示有残留？
副本集环境下，deleteMany 在主节点返回成功后，从节点同步有延迟。如果紧接着在 mongos 或从节点上执行 countDocuments()，很可能读到旧快照，看到“删了但还有几条”。这不是数据丢失，而是最终一致性窗口期。
更麻烦的是 TTL 索引清理：它由后台线程异步执行，延迟不可控，且不响应 deleteMany 的 write concern 设置，所以千万别把 TTL 当作批量清理的替代方案。
- 验证是否真删完，必须连主节点查：
db.runCommand({ isMaster: 1 }).ismaster === true - 生产环境关键清理后，加一段等待逻辑：
db.fsyncLock()+db.fsyncUnlock()强制刷盘（仅限非 Atlas 环境） - 别依赖
deletedCount为唯一依据——它只反映主节点本地结果，不保证全局可见
