TTL索引适合中小日志量（日增百万级以下），需确保log_time为Date类型、单字段建索引、容忍60秒扫描延迟；日增超百万时应分表以规避性能瓶颈。
直接结论：TTL索引适合中小日志量（日增 logs_20260513）+ 定期 dropCollection，否则 TTL 会失效、卡顿甚至拖垮集群。
为什么 TTL 索引在日志场景下容易“假生效”
TTL 索引不是“开关”，它依赖三个硬性条件同时满足才能触发清理：字段必须是顶层 Date 类型、不能为 null 或缺失、集合必须有持续写入（否则后台线程可能跳过该集合）。日志数据天然破坏这些条件：
- 时间字段名不统一：
time、@timestamp、metadata.ts—— 后两者无法建 TTL 索引（不支持嵌套路径，也不接受字符串） - 入库时未转换类型：Python 写入
"2026-05-13T04:15:00Z"字符串，MongoDB 不自动解析，索引建了也白建 - 存在大量空值：
db.logs.countDocuments({"log_time": null})> 0 会导致对应文档永久滞留，且不报错
怎么让 TTL 索引真正跑起来（仅限字段可控场景）
如果你能统一日志结构（比如所有服务都打 log_time: datetime），才值得走 TTL 路线。操作要点很具体：
- 入库前强制转类型：Python 用
datetime.fromisoformat()或dateutil.parser.parse()，存为顶层字段log_time - 建索引只写单字段：
collection.create_index("log_time", expireAfterSeconds=86400)—— 别加复合条件，TTL 不认 - 上线后立刻验证：
db.logs.findOne().log_time.constructor === Date必须返回true；再查db.logs.getIndexes()确认expireAfterSeconds出现在输出里 - 容忍延迟：后台线程默认每 60 秒扫描一次，设 3600 秒过期，实际删除可能晚最多 61 秒
日增百万级日志时，为什么必须分表（logs_20260513）
当单集合文档数突破 500 万，TTL 的后台扫描就会明显拖慢写入吞吐，尤其在副本集主节点上。分表不是“多此一举”，而是绕开 MongoDB 内核限制的务实选择：
- 清理快两个数量级：
db.dropCollection("logs_20260512")是元数据操作，毫秒级完成；TTL 扫描删除千万文档要分钟级 - 避免索引膨胀：TTL 索引本身要维护 B-tree，日志字段高频写入会引发频繁页分裂，而分表后每个集合索引极小
- 天然支持冷热分离：旧表可
mongodump归档后删掉，新表保持活跃，运维边界清晰 - 注意点：别用
GridFS存日志——它把每条小日志拆成多个chunks，fs.files集合会成为写入瓶颈，查询也完全不可行
自动清理失败时，最先查哪三件事
发现日志体积不降，别急着重跑脚本。先在 mongo shell 里敲这三条命令：
-
db.logs.countDocuments({"log_time": { $type: "date" }})—— 如果结果远小于总文档数，说明类型没转对 -
db.logs.countDocuments({"log_time": null})+db.logs.countDocuments({"log_time": { $exists: false }})—— 任一结果 > 0，这些文档就永远卡住 -
db.adminCommand({serverStatus: 1}).metrics.ttl—— 查passes是否在增长，deletedDocuments是否为 0；若长期不动，可能是版本 ttlMonitorEnabled 被关了
最常被忽略的点是：TTL 不是“设置即生效”，它高度依赖数据写入节奏和字段洁度。字段乱、类型错、空值多，建了索引也等于没建。分表看着土，但在海量日志场景下，反而是最稳、最快、最容易监控的方案。
