drop()清空集合最快，毫秒级完成，直接删除文件、索引和统计信息；deleteMany({})保留结构但性能差，多索引时更慢；remove()已废弃。
直接 drop 集合比 deleteMany 快几个数量级
如果你的业务已按月分表（如 logs_202501、logs_202502），且目标是清空整个月份的数据，drop() 是唯一真正“快速”的选择。它不扫描文档、不更新索引条目、不写 oplog 单条日志，而是直接卸载整个集合的元数据和数据文件。实测在 WiredTiger 引擎下，一个含 800 万文档、5 个复合索引的集合，drop() 耗时通常 deleteMany({}) 可能需 40+ 秒，且期间会持续占用写锁和内存。
drop() 前必须确认三件事
不是所有“按月分表”都适合无脑 drop()，以下任一条件不满足，就该切回 deleteMany()：
-
集合上存在 TTL 索引：drop 后重建时不会自动恢复 TTL 行为，需手动重加createIndex({expireAt: 1}, {expireAfterSeconds: 0}) -
集合已分片：drop 在分片集群中虽原子，但会触发 balancer 清理 chunk 元数据，若 chunk 数量极大（>10k），可能短暂影响路由稳定性 -
有 Change Stream 正在监听该集合：drop 会立即中断流，并导致下游消费者收到invalidate事件——如果消费逻辑没处理该事件，可能卡死或丢数据
脚本里别用 remove()，也别手写 {} 的等效变体
遗留脚本中常见的 db.logs_202501.remove({}) 或 db.logs_202501.deleteMany({_id: {$exists: true}}) 都是危险操作：
-
remove()在 MongoDB 5.0+ 已完全移除，PyMongo 4.0+ 驱动调用直接抛AttributeError -
{_id: {$exists: true}}在某些旧版本驱动中可能被错误优化为全表扫描跳过，导致漏删；而{}是唯一被所有版本明确语义为“匹配全部文档”的空条件 - 即使你坚持用
deleteMany({})，也务必检查返回值：result.deletedCount必须等于db.logs_202501.countDocuments({})，否则说明有未提交事务或读隔离问题
drop 后磁盘空间不立刻释放，但这是正常现象
WiredTiger 引擎下，drop() 仅归还内存和元数据，底层 .wt 文件不会马上从磁盘删除——它被放入内部回收队列，由后台线程逐步清理。这意味着：
- 执行
db.logs_202501.drop()后，db.stats().dataSize会立刻下降，但系统du -sh看到的磁盘占用不变 - 无需手动跑
compact：该命令已废弃（5.0+ 不支持），且对 drop 后的碎片无效 - 真正释放时机取决于
wiredTiger.engineConfig.diskFreeThresholdMB和后台清理节奏，一般几小时到一天内完成
最常被忽略的一点：分表命名必须严格可预测，且 drop 操作应包裹在 db.getSiblingDB("admin").runCommand({setParameter: 1, logLevel: 0}) 之前临时降级日志级别——否则大量 drop 会刷爆 oplog 和审计日志，尤其在副本集里可能拖慢 secondary 同步。
