drop()是清空集合最快的方式，直接删除文件、索引和统计信息，毫秒级完成；deleteMany({})保留结构但性能差，尤其多索引时；remove()已废弃，应替换为deleteMany({})。
drop() 是清空集合最快的方式，但不可逆
如果你的目标只是把整个集合的数据和结构一并清除，drop() 是唯一真正“快速”的选择。它直接删除集合文件、索引、统计信息，不逐条扫描文档，也不触发任何写入日志（WAL）级别的单文档操作。实测在 1000 万级文档的集合上，drop() 通常在毫秒级完成；而 deleteMany({}) 可能需要数秒甚至分钟，尤其当存在多个索引时。
注意：drop() 后集合彻底消失，再次插入数据会重建索引——这本身有开销，但远小于逐条删除再重建。如果集合后续还会高频写入，且你确定不需要保留结构（如 schema、TTL 索引、分片配置等），drop() 是首选。
- 执行前无需检查集合是否存在，
db.collection.drop()对不存在的集合也返回true - 不会释放磁盘空间（WiredTiger 引擎下），但会归还内存中该集合占用的资源
- 副本集或分片集群中，
drop()是原子性操作，主节点执行后自动同步到从节点
deleteMany({}) 适合需保留集合结构的场景
当你必须保留集合的索引、验证规则、分片键、TTL 设置或触发器（如 Change Streams 监听），就不能用 drop()。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% 时间花在索引树的 rebalance 上，而非文档存储层。而 drop() 绕过所有这些，直接删掉整个 namespace。
- 若必须用
deleteMany({})且数据量大，建议先db.collection.dropIndex()删除非必要索引，删完再重建 - WiredTiger 下观察
db.serverStatus().metrics.record.moves可判断是否因空间碎片导致性能下降 - 不要依赖
db.collection.stats().size判断“真实”数据大小，它包含未回收空间，应看storageSize和totalSize
drop()，如果集合被频繁重建，WiredTiger 的 cache pressure 和 journal 文件增长仍可能拖慢后续写入——这时得结合 collMod 调整集合选项，或改用 timeseries 集合做冷热分离。 
