不能直接用 delete_many() 一次性删除，因其会锁表、占内存、触发超时，导致主节点卡顿；应分批查删，用 expires_at 与 _id 复合索引、_id 稳定分页、持久化断点，并避免依赖 ttl 索引。
为什么不能直接用 delete_many() 一次性删完？
因为过期数据量大时，delete_many() 会锁表、占满内存、触发超时，甚至让 MongoDB 主节点卡住几秒到几十秒。生产环境里这等于服务抖动。真正可行的做法是分批查 + 分批删，每次只操作几千条，让写入和查询不受影响。
怎么安全地分批查出过期文档？
关键不是“查”，而是“查得准、不漏、不重复”。必须用带排序和游标的方案，避免时间字段重复导致跳过或重删：
- 用
created_at或expires_at字段做范围查询（别用$lt单条件查全部，容易全表扫描） - 每次查都加
.sort("_id").limit(5000)，靠_id做稳定分页（ObjectId 时间有序且唯一） - 记录上一批最后的
_id，下一轮查{"_id": {"$gt": last_id}, "expires_at": {"$lt": now}} - 务必在
expires_at和_id上建复合索引：db.collection.createIndex({"expires_at": 1, "_id": 1})
删除时如何防止误删或中断后状态丢失？
分批删本质是“查→删→记位点”三步，任何一步失败都会导致重复或遗漏。实际要这样做：
- 每次删前先
find()拿到这批文档的_id列表（不是直接delete_many()带条件删） - 用
delete_many({"_id": {"$in": id_list}})精确删这批 - 删成功后，把最后一个
_id写入一个临时控制集合（如cleanup_state），含时间戳和批次号 - 脚本启动时先读这个控制集合，从断点继续；没记录就从头开始
- 避免用时间范围分批（比如“每小时删一次”），因为同一秒可能有成千文档，时间字段不唯一
要不要用 MongoDB 的 TTL 索引自动删？
TTL 索引只适合“插入即确定过期时间”的场景，比如 session、缓存、日志。它不支持动态计算过期时间（如 created_at + 7 days），也不能按业务逻辑判断（如“用户已注销且数据超 30 天”）。一旦用了 TTL，你就没法控制删的节奏、监控进度、或回滚——它在后台悄悄跑，出问题很难排查。
真正需要灵活性和可观测性时，手写分批删脚本仍是更可控的选择。复杂点在于状态管理，最容易被忽略的是：没做索引、没用 _id 分页、没持久化断点位置。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
