drop() 是原子性文件级删除，deleteMany({}) 是逐文档标记删除；前者直接卸载元数据与文件、毫秒级完成、几乎不产生oplog，后者需遍历文档、标记删除、耗时线性增长、触发大量日志与锁竞争。
drop() 是原子性文件级删除，deleteMany({}) 是逐文档标记删除
根本区别在底层动作：drop() 直接卸载整个集合的元数据、数据文件、索引文件和统计信息，不扫描任何文档；deleteMany({}) 则必须遍历每一条匹配文档，在 WiredTiger 引擎中只是把对应记录标记为“已删除”，仍保留在 .wt 文件里，等待后台清理或后续复用。
这意味着：drop() 耗时基本与集合大小无关，10 万条和 1000 万条都毫秒级完成；deleteMany({}) 的耗时随文档数线性增长，且每多一个索引，就要额外更新一次索引条目——5 个索引时实际 I/O 开销可能翻 4–5 倍。
deleteMany({}) 触发大量写入日志和锁竞争，drop() 几乎不产生 oplog 流量
deleteMany({}) 对每个被删文档都会生成一条 oplog 条目，复制集里要同步到多数节点，还会持有集合写锁较长时间，容易阻塞其他写操作；而 drop() 是单条元数据变更操作，只产生一条 oplog（类型为 "drop"），主节点执行后由 mongos 或副本集自动广播，几乎不卡住其他请求。
常见误判点：
- 以为
deleteMany({})加了{ writeConcern: { w: "majority" } }就安全——它只保证日志落盘，不解决锁和 I/O 压力问题 - 在分片集群中对大集合跑
deleteMany({})，mongos 会把它拆成多个子命令下发到各分片，但每个分片仍需独立扫描+删+更新索引，效率远低于drop()的直接 chunk 卸载
磁盘空间释放行为完全不同
deleteMany({}) 后 db.collection.stats().size 和 storageSize 可能几乎不变，因为 WiredTiger 只做逻辑删除；drop() 后 storageSize 立即归零（内存中释放），.wt 文件进入后台回收队列，几小时到一天内由引擎自动清理并返还给操作系统。
注意：这不是 bug，是 WiredTiger 的设计。你不能靠 deleteMany({}) 解决磁盘满的问题——真正有效的只有 drop() 或手动 compact()（但后者在 MongoDB 5.0+ 已废弃，且只对未 drop 的集合部分有效）。
真正麻烦的不是性能，而是 drop() 后集合“消失”带来的隐性依赖断裂
drop() 不仅删数据，还一并清除：validator、collation、TTL 索引、隐藏的 viewOn、change stream 监听状态、某些 ORM 缓存的集合结构信息，甚至监控工具里预设的“该集合存在”告警规则。
所以生产环境慎用 drop() 的真实原因从来不是慢，而是：你是否清楚所有下游系统都已适配“集合可能不存在”这个事实。如果不确定，宁可多花几十秒跑 deleteMany({}) 并加好超时和校验，也别赌一次 drop() 后的连带故障。
