MongoDB批量删除过慢耗尽IOPS，求优化方案

一、先砍索引，从根源降低IO开销 #

• 临时移除非核心索引：只保留删除操作必须用到的索引（比如_id主键索引），剩下20+个非必要索引全部删掉。等删除任务完成后，再重新创建这些索引。毕竟每删一条记录，23个索引都要同步更新，这是IOPS直接拉满的核心原因。
• 强制用_id做删除条件：如果待删除集合里存的是主键_id，直接用db.target_collection.deleteMany({_id: {$in: [...待删ID列表]}})，主键索引是MongoDB里最快的索引，能最大程度减少查询和删除的耗时。

二、调整批次策略，避开业务高峰 #

• 切换到小批次+短间隔：把批次大小降到500-1000条/批，间隔改成10-30秒，而不是之前的几分钟。长时间间隔不会缓解IO压力，反而会让索引碎片越积越多；短间隔小批次能让MongoDB更高效地利用缓存和预读机制。
• 标记已处理的待删ID：给存待删ID的集合加个processed字段，每次取{processed: false}的前N条ID，删除完成后把这些ID标记为true。别用skip来翻页，大数据集里skip会越来越慢，标记字段的方式更高效，还能避免重复删除。
• 全量移到业务低峰期执行：比如凌晨0-6点业务流量最低的时候集中跑删除任务，避免和正常业务查询抢IO资源。

三、减轻副本节点的同步压力 #

• 临时调整副本同步策略：把两个副本节点的priority设为0，暂时不让它们参与选举，或者直接临时停止副本同步（删除完成后再重新同步）。主节点每次删完数据都要把oplog同步给副本，这部分IO开销占比不小，先砍掉能大幅减轻主节点负担。
• 检查并调大oplog大小：如果oplog容量太小，副本节点可能跟不上同步节奏，主节点会一直等副本确认，拖慢删除速度。MongoDB 4.2及以上版本支持在线调大oplog，直接执行db.adminCommand({replSetResizeOplog: 1, size: 10240})（单位是MB，按需调整）。

四、降低删除操作的锁与等待开销 #

• 临时降级写关注：默认写关注是w:1（等主节点确认删除完成），如果业务允许数据有短暂的不一致风险，可以改成w:0，不用等待确认直接发删除请求，能省不少等待时间。事后可以校验待删ID是否都处理完毕。
• 确认开启文档级锁：MongoDB 3.0+默认是文档级锁，不会因为删一批数据锁住整个集合。如果是更老的版本，赶紧升级，表级锁会把正常业务查询全堵死。

五、处理IOPS瓶颈与磁盘碎片 #

• 临时提升存储IO配额：如果是云服务商的MongoDB实例，联系服务商临时调高IOPS上限，或者切换到更高性能的SSD存储，先撑过删除任务。
• 间隙清理磁盘碎片：删除过程中会产生大量磁盘碎片，导致后续IO变慢。可以在批次间隔里低峰期执行db.target_collection.compact()，但注意这个命令会锁集合，一定要选没人用的时候跑。

六、换个思路：迁移保留数据而非删除 #

因为你要删的是10%的数据（1500万/1.5亿），不如直接新建集合迁移需要保留的数据：

1. 新建临时集合new_target_collection
2. 用聚合管道把需要保留的数据导过去：

   db.target_collection.aggregate([
     {$match: {_id: {$nin: db.delete_ids.distinct('_id')}}}
   ], {allowDiskUse: true, out: 'new_target_collection'})
   

3. 验证新集合的数据量和内容正确后，删除旧集合，把新集合重命名为原集合名
4. 重新创建所有需要的索引

这种方式不会产生大量删除操作的IO开销，而且建索引可以一次性完成，比逐条删效率高得多。

内容的提问来源于stack exchange，提问作者Bogdan Dubyk