MongoDB清空集合：选drop()还是deleteMany({})？
开门见山，先说结论：想最快清空集合，drop()是唯一正确的答案。它直接删除文件、索引和统计信息，整个过程毫秒级完成。而deleteMany({})虽然保留了集合结构，但性能差距巨大，尤其是在存在多个索引的情况下。至于remove()，这个命令已经废弃，别再用了。
drop() 是清空集合最快的方式，但不可逆
如果你的目标简单粗暴——就是把整个集合连数据带结构从数据库里抹掉，那么drop()就是性能之王。它的原理很直接：不跟你逐条扫描文档，而是直接删除底层的集合文件、相关的所有索引以及统计信息，连写入日志（WAL）级别的单文档操作都不会触发。实测下来，面对一个千万级文档的集合，drop()通常在毫秒内就能搞定；而换成deleteMany({})，你可能得等上几秒甚至几分钟，索引越多，这个时间差就越明显。
当然，天下没有免费的午餐。drop()之后，集合就彻底消失了，包括你精心设计的schema、TTL索引、分片配置等等。后续再插入数据，索引需要重建，这本身确实有开销，但比起一条条删除文档再重建索引，这个代价要小得多。所以，如果你的场景是确定后续会高频写入，且不需要保留任何现有结构，闭着眼睛选drop()就对了。
- 执行前你甚至不用检查集合是否存在，
db.collection.drop()对不存在的集合也会返回true。 - 在WiredTiger引擎下，它不会立即释放磁盘空间，但会归还内存中该集合占用的所有资源。
- 在副本集或分片集群环境中，
drop()是一个原子性操作，主节点执行后会自动同步到从节点。
deleteMany({}) 适合需保留集合结构的场景
那么，什么时候不能用drop()呢？答案很简单：当你必须保留集合的“骨架”时。比如，集合上定义的索引、数据验证规则、分片键、TTL设置，或者正在被Change Streams监听，这些元数据你都想留着，那么deleteMany({})就是唯一安全的选择——它只删除文档，不动结构。
但性能代价是显而易见的。每删除一条文档，MongoDB都需要从每一个关联的索引中移除对应的条目。索引越多，文档越零散，这个过程就越慢。实测数据表明，一个带有5个复合索引的集合，执行deleteMany({})的速度会比没有索引时慢上3到5倍。
- 这里有个关键细节：务必确保查询条件是空对象
{}，而不是{_id: {$exists: true}}或其他看似等效的写法，否则可能导致漏删或性能误判。 - 执行后，返回结果中的
deleted_count字段会告诉你实际删除了多少文档，可以用来校验清空是否成功。 - 同样，在WiredTiger引擎下，磁盘空间不会立即回收，需要后续执行
compact命令或等待后台的清理进程。
remove() 已废弃，别再用
现在来说说remove()。这个命令在MongoDB 4.2+版本中就被标记为废弃了，到了5.0+版本则被完全移除。即便你在一些旧的驱动里还能调用它，其底层行为也已经被映射为deleteMany()，但问题在于它的语义模糊、参数容易产生歧义（比如justOne参数就很容易设错），而且不返回删除计数，调试起来非常麻烦。
所以，如果你在遗留代码或shell脚本里看到db.coll.remove({})，请立刻、马上把它替换成db.coll.deleteMany({})。现代的mongosh会给出明确的警告，而像PyMongo这样的现代驱动，则干脆不提供这个方法了。
- 在PyMongo中，尝试调用
collection.remove()会直接抛出一个AttributeError。 - 在Shell中执行
remove()可能还能运行，但返回的结果里没有deletedCount字段，你根本无法确认到底删没删。 - 对于所有新项目、自动化脚本和CI/CD流水线，一个明确的原则是：彻底剔除
remove()的任何使用痕迹。
真正影响速度的，往往不是方法本身，而是索引和引擎行为
话说回来，很多人在对比drop()和deleteMany({})时，只盯着方法名看，却忽略了背后两个更关键的事实：第一，WiredTiger存储引擎不会主动归还磁盘空间；第二，更新索引的成本，往往远高于删除文档本身。
举个例子，对一个拥有3个二级索引的集合执行deleteMany({})，你会发现90%的时间其实都花在了索引树的重新平衡上，而不是在文档存储层进行操作。而drop()则绕过了所有这些繁琐的步骤，直接删掉了整个命名空间。
- 如果必须使用
deleteMany({})且数据量巨大，一个实用的建议是：先通过db.collection.dropIndex()删除非必要的索引，等数据清空后再重建它们。 - 在WiredTiger引擎下，观察
db.serverStatus().metrics.record.moves这个指标，可以帮助你判断是否因为空间碎片化导致了性能下降。 - 不要依赖
db.collection.stats().size来判断“真实”的数据大小，这个值包含了未回收的空间。你应该关注storageSize和totalSize。
最后，还有一个真正容易被忽略的细节：即便你用了最快的drop()，如果这个集合被频繁地删除又重建，WiredTiger引擎的缓存压力（cache pressure）和日志文件（journal）的增长，仍然可能拖慢后续的写入操作。这时候，你可能需要结合collMod命令来调整集合的选项，或者考虑改用时序集合（timeseries collection）来实现冷热数据的分离。这才是应对高频清空场景的治本之策。
