deleteMany() 是 MongoDB 中最常见的数据删除方法，但如果直接清理大量历史数据，往往容易引发卡顿、锁表，甚至影响线上读写性能；而 drop() 则是按月分表场景下清空整张集合最快、效率最高的方案。实际操作时，还需要重点校验时间字段类型、提前创建索引、核对删除结果，并留意分片集群、Change Stream 等因素带来的影响。

用 deleteMany() 删除指定日期前的数据

这种方式适合不能丢失集合结构、字段分布不固定，或者只需要删除部分月份历史数据的场景。关键在于时间条件必须写准确，同时注意时区和字段类型校验：

• 时间字段必须是 ISODate 类型，不能是字符串——建议先用 db.collection.find().limit(1) 检查一下字段实际存储格式。如果是 "2025-01-01" 这类字符串，使用 $lt 比较时会按字典序处理，结果可能出现错误
• 在 Python 示例中，务必使用 datetime.now(timezone.utc)，不要使用 datetime.now()（本地时区）或 datetime.utcnow()（无时区对象），否则在跨时区部署环境下很可能出现历史数据漏删的问题
• 建立索引可以显著提升 MongoDB 按日期删除数据的效率：如果经常按 created_at 清理，建议创建单字段索引 db.collection.createIndex({created_at: 1})；如果删除条件是复合过滤，例如 {status: "archived", created_at: {$lt: ...}}，则应建立对应的复合索引
• 面对大数据量集合时要格外谨慎：例如 800 万条文档并带有 5 个索引时，执行 deleteMany({created_at: {$lt: cutoff}}) 可能持续 40 秒以上，这段时间内写锁可能阻塞其他正常操作

用 drop() 直接清空整个月份集合（最快）

如果你的 MongoDB 已经按月份进行了分表，例如 logs_202501、logs_202502，并且目标就是删除某整个月份的历史数据，那么使用 drop() 往往是最快、最直接的方案，通常可以达到毫秒级处理速度：

• db.logs_202501.drop() 不需要扫描数据、不需要逐条更新索引，也不会逐笔处理删除逻辑，而是直接卸载集合的元数据和数据文件
• 执行完成后，db.stats().dataSize 会明显下降，但磁盘层面的 du -sh 可能暂时没有变化——这是因为 WiredTiger 会在后台异步回收空间，真正释放磁盘通常需要数小时到一天左右
• 操作前一定要确认三件事：是否存在 TTL 索引（drop 后不会自动恢复）、集合是否已经 分片（当 chunk >10k 时可能短暂影响路由）、是否有 Change Stream 正在监听（会触发 invalidate 事件，如果下游没有处理机制可能直接卡住）
• 脚本中不要再使用 remove({}) 或 deleteMany({_id: {$exists: true}}) 这类写法——前者在 MongoDB 5.0+ 中已经被移除，后者在部分旧驱动环境里可能因为错误优化而出现漏删

为什么 TTL 索引不适合主动清理？

TTL 索引更适合“数据写入后自动过期”的场景，例如 session、临时 token 等；但如果你是想按业务节奏主动批量清理历史日志或历史数据，它并不是理想方案：

• 删除延迟不可控：后台线程通常每 60 秒扫描一次，在高峰期甚至可能积压几分钟，因此即使刚执行完 createIndex，数据也不会立刻被删除
• 不支持复合过滤条件：TTL 只能依赖单个日期字段，无法结合 {type: "error"} 这类业务条件进行更精细的清理
• 缺乏审计能力：哪些数据被删、删除了多少、具体何时删除，默认都没有完整记录，出现问题时很难回溯
• 一旦索引建错，例如目标字段不是 Date 类型，文档就会一直保留，不仅删除失败，还会额外占用索引空间

删完怎么验证没漏？

不要只看 result.deletedCount，因为它只表示命令返回时的删除计数；在事务隔离、复制延迟或未提交写入的情况下，这个数字可能和真实结果存在偏差：

• 删除前先统计匹配数量：db.collection.countDocuments({created_at: {$lt: cutoff}})
• 删除后立即再次查询：db.collection.find({created_at: {$lt: cutoff}}).limit(1)，通过抽样确认是否仍有符合条件的数据残留
• 如果删除的是按月分表集合，还应检查集合名是否仍然存在：db.getCollectionNames().includes("logs_202501") —— 在执行 drop() 后，这个名称应当消失
• 需要注意的是，在副本集环境中，主节点执行 drop() 后，从节点的数据同步可能存在延迟，建议通过 rs.status() 查看 optime 是否已经追平