优先用drop()清空集合，因其原子性删除文件、索引及元数据，毫秒级完成；deletemany({})仅逐条删文档、保留结构且性能差，易引发锁阻塞与主从延迟。
直接用 db.collection.drop() 或 db.collection.deleteMany({}) 清空千万级集合，在生产环境极大概率引发长时间写锁、主从延迟飙升、查询超时甚至服务雪崩——这不是清表，是停服。
为什么 deleteMany({}) 在大表上很危险
它本质是一次性发起全量文档扫描 + 逐条标记删除 + 触发WiredTiger引擎的page-level清理，期间持续持有集合级别的写锁（尤其在MMAPv1引擎下更严重），且会产生巨量oplog，拖慢复制。实测 2000 万文档的集合执行该命令，可能卡住 8–15 分钟，期间所有写入和部分读操作被阻塞。
- oplog 写入暴增，从节点同步滞后可能突破 30 分钟以上
- WiredTiger cache 压力陡升，频繁触发 eviction，连带影响其他集合查询性能
- 如果集合有 TTL 索引或大量二级索引，删除过程会额外遍历并更新索引项，进一步拉长耗时
真正可行的替代方案：用 drop() + 快速重建索引
只要业务能接受「集合短暂不可用」（通常控制在秒级），drop() 是最安全、最快速的选择。它不走文档级清理流程，而是直接释放文件系统空间、清空内存映射、重置元数据，整个过程几乎无锁。
- 确保集合没有被其他应用强依赖（比如实时报表服务正在轮询该集合）
- 提前在从节点上确认
rs.status()中无严重延迟，避免drop后主从状态异常 -
drop()后立刻用createIndex()重建必需索引，不要等第一次查询触发 lazy index build - 若需保留集合结构（如 validator、collation），先用
db.runCommand({collMod: ..., validator: ...})记录配置，drop后再createCollection()并恢复
必须用 delete 的场景：如何分批安全执行
当业务要求「零中断」且无法接受 drop（例如该集合被多个微服务共享，且无统一协调窗口），只能分批删，但必须绕过默认游标行为：
- 用
find().limit(N).sort({_id: 1})+deleteMany({ _id: { $lt: lastId } })模式，每次删固定 ID 区间，N 控制在 5000–10000（太大易超时，太小请求过多） - 务必加
{ writeConcern: { w: "majority", j: true } }避免主从不一致 - 每批之间 sleep 100–500ms，给 WiredTiger 缓冲区和 oplog 复制留出喘息时间
- 监控
db.serverStatus().metrics.operation中delete和repl.apply延迟，一旦发现从节点 lag > 5s，立即暂停
容易被忽略的关键点
很多人只盯着删除动作本身，却忘了清理后的连锁反应：
- 删除后磁盘空间不会立刻返还给操作系统（WiredTiger 默认启用
cache_size和use_mmapv1已弃用，但旧部署仍存在），需手动运行db.runCommand({compact: "collectionName"})（注意：该命令会阻塞集合 10–30 秒，仅限维护窗口） - 如果集合启用了
change stream，drop()会触发drop事件，下游监听服务必须能正确处理该事件，否则可能 crash 或重复消费 - 备份策略要同步更新——
mongodump不会包含已drop的集合，但oplog备份里仍有对应记录，恢复时需注意时间点选择
