delete_many()按时间字段批量删除比TTL索引更可控，关键在于删得准、不误伤；需校准时区、确认字段类型、分批滚动清理、验证残留与索引膨胀。
用 delete_many() 按时间字段批量删除过期文档
直接删比设TTL索引更可控，尤其当过期逻辑不单纯依赖插入时间（比如按业务生效时间、用户最后活跃时间等）。关键不是“能不能删”，而是“删得准不准、会不会误伤”。
常见错误是用 datetime.utcnow() 但没对齐时区，或把字符串时间当 datetime 对象比较。MongoDB 的 $lt 只能和同类型字段比较，字段存的是 ISODate("2023-01-01T00:00:00Z")，你就不能传字符串 "2023-01-01" 进去。
- 先确认时间字段类型：用
db.collection.find_one({}, {"updated_at": 1})看返回值里updated_at是datetime还是字符串 - 构造正确的时间对象：用
datetime.datetime.fromisoformat()解析 ISO 字符串；若字段是 UTC 时间，统一用datetime.datetime.now(datetime.timezone.utc)生成基准时间 - 加
limit参数预估影响范围：collection.count_documents({"updated_at": {"$lt": cutoff}})先查数量，别一上来就删
避免阻塞写入的分批删除策略
单次 delete_many() 删除几百万文档会锁表、拖慢线上写入，尤其在 WiredTiger 引擎下可能触发大量 page fault。必须拆成小批次，但不是简单套个 for i in range(0, total, 1000) —— MongoDB 没有 OFFSET，靠跳过方式分页效率极低。
正确做法是用“游标 + 范围条件”滚动清理：
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
立即学习“Python免费学习笔记（深入）”；
- 每次删前先查出本批最小 ID 或时间戳：
oldest = collection.find({"updated_at": {"$lt": cutoff}}, sort=[("updated_at", 1)], limit=1) - 用该时间戳作为下一批起点条件：
{"updated_at": {"$lt": cutoff, "$gte": last_cutoff}} - 每批控制在 1000–5000 条，用
delete_many()带{"updated_at": {"$lt": cutoff, "$gte": batch_start}}条件 - 加
sleep(0.1)避免连续高压请求，尤其在副本集主节点上
TTL 索引只适合严格按插入时间过期的场景
create_index("created_at", expireAfterSeconds=86400) 看起来省事，但实际限制很多：只能作用于根级字段、不能用复合条件（比如“已支付且创建超7天”）、后台任务每60秒扫描一次，延迟不可控。更麻烦的是——它删的是整个文档，没法配合业务逻辑做软删、归档或触发回调。
- 仅当字段名固定为
created_at或_id（ObjectId 时间戳），且过期规则就是“插入后 N 秒”时才考虑 TTL - 务必检查字段是否已存在非空值：如果历史数据该字段为
null，TTL 索引会跳过这些文档，导致漏删 - 生产环境启用前，在从节点上先
db.runCommand({ "collMod": "logs", "index": { "keyPattern": { "created_at": 1 }, "expireAfterSeconds": 86400 } })测试效果
清理后验证残留数据与索引膨胀
删完不等于真干净。WiredTiger 默认不会立即回收磁盘空间，db.collection.stats() 里的 size 和 storageSize 可能长期不降；更隐蔽的是，如果原来有复合索引包含被删字段，碎片率上升会影响后续查询性能。
- 用
db.collection.validate({full: true})检查文档完整性，特别留意deletedCount是否匹配预期 - 观察
db.serverStatus().metrics.document.deleted计数器变化趋势，确认没有其他进程在写入干扰 - 若存储空间未释放，需执行
db.runCommand({compact: "collection_name"})（注意：该命令会阻塞读写，安排在低峰期）
真正麻烦的不是删动作本身，而是删完之后没人看 storageSize 和索引 avgObjSize——这些数字沉默地告诉你，磁盘还在虚胖。
