不能直接用create_index给日志集合加TTL索引，因为TTL索引要求Date类型且必须是顶层字段，而日志时间字段名不统一、常为字符串或嵌套结构，导致索引无效。
为什么不能直接用 create_index 给日志集合加普通 TTL 索引
因为日志文档通常没有标准的 created_at 或 timestamp 字段——可能叫 time、ts、@timestamp，甚至嵌套在 metadata 里。MongoDB 的 TTL 索引只认 Date 类型字段，且必须是顶层字段（不支持 "metadata.ts" 这种点号路径）。如果字段类型是字符串（如 "2024-05-20T10:30:00"），索引建了也无效，后台线程不会删除。
实操建议：
- 入库前统一转换时间字段：用
datetime.fromisoformat()或dateutil.parser.parse()转成datetime对象，存为顶层log_time字段 - 建索引时指定该字段：
collection.create_index("log_time", expireAfterSeconds=86400)（保留 1 天） - 验证是否生效：查
db.getCollection('logs').getIndexes()，确认输出里有{"key": {"log_time": 1}, "expireAfterSeconds": 86400} - 注意：TTL 删除由后台线程每 60 秒扫描一次，不是实时的；且只删整条文档，不能只删旧字段
日志量超单机磁盘上限时，为什么不该直接上 GridFS
GridFS 是为「大文件」设计的（比如图片、视频分片存储），不是为高频小文档（如每条
- 每个日志被拆成多个
chunks文档，元数据膨胀严重，索引体积翻倍 -
fs.files集合会成为热点，写入吞吐骤降（尤其并发高时争抢_id） - 无法对日志内容做高效查询（例如
{"level": "ERROR"}），得先读完整个file_id再解析，延迟不可控
更合理的做法是分片集群 + 时间分片（time-based sharding）：
立即学习“Python免费学习笔记（深入）”；
- 按天或按小时建独立集合，如
logs_20240520、logs_20240521 - 用
mongos做路由，按log_time哈希或范围分片 - 清理时直接
db.dropCollection("logs_20240520")，比 TTL 扫描快两个数量级
自动清理失败的三个典型信号和对应检查项
现象：日志集合大小持续增长，db.logs.stats().size 不降，但 log_time 里大量数据已超期。
- 检查字段类型：
db.logs.findOne().log_time.constructor === Date必须返回true，否则索引失效 - 检查是否有
null或缺失值：db.logs.countDocuments({"log_time": null})> 0 会导致该文档永远不被 TTL 清理 - 确认 MongoDB 版本 ≥ 3.2（TTL 索引最低要求），且未禁用后台任务：
db.adminCommand({setParameter: 1, ttlMonitorEnabled: true}) - 查看日志：
grep "TTL" /var/log/mongodb/mongod.log，若出现"TTL job skipping collection"，说明集合被跳过（常见于 capped collection 或权限不足）
Python 写入时怎么避免阻塞和丢日志
用 pymongo 直接同步 insert_one 在高并发下极易拖慢主业务。关键不是“怎么连”，而是“怎么缓冲+降级”。
- 启用无确认写入：
collection.insert_one(doc, write_concern=WriteConcern(w=0))，牺牲强一致性换吞吐 - 加内存队列（如
queue.Queue）+ 单独线程批量刷库：collection.insert_many(batch, ordered=False) - 配置连接池上限：
MongoClient(maxPoolSize=50, minPoolSize=10)，防连接数爆炸 - 务必设置超时：
socketTimeoutMS=3000和serverSelectionTimeoutMS=2000，避免网络卡住整个应用
TTL 索引本身不解决写入压力，但它让清理逻辑变得可预测；真正扛住海量日志的，是分片策略、写入缓冲和字段规范化这三件事的组合。别指望一个索引命令包打天下。
