TTL索引仅支持Date类型字段，因底层依赖时间戳计算；expireAfterSeconds表示从字段值时间起再延时删除，非插入后计时；不生效常见原因包括分片配置不当、字段值非Date、主节点切换延迟扫描。
TTL索引是MongoDB原生支持的自动清理机制，但仅适用于单字段、日期类型字段，且删除动作由后台线程异步触发，不能保证精确到秒级删除。
为什么TTL索引只对Date类型字段生效
MongoDB的TTL索引底层依赖字段值与当前时间的差值计算过期时间，只有Date类型能被正确解析为时间戳。若字段是字符串（如"2025-04-01T12:00:00Z"）或数字（如1743508800000），即使语义上表示时间，TTL也不会识别——插入时不会报错，但文档永远不会被清理。
- 必须确保字段存储的是BSON
Date类型，可用typeof doc.createdAt === 'object'和doc.createdAt instanceof Date在应用层校验 - 聚合管道中用
$dateFromString转换字符串后写入，不能直接建TTL索引在原始字符串字段上 - 使用
mongosh验证字段类型：db.collection.findOne().expireAt→ 查看返回值是否为ISODate(...)
createIndex中expireAfterSeconds的实际含义
expireAfterSeconds不是“从插入起多少秒后删除”，而是“从字段值对应的时间起，再过多少秒后删除”。例如字段叫expireAt，值为ISODate("2025-04-01T10:00:00Z")，设置{ expireAfterSeconds: 3600 }，则该文档会在2025-04-01T11:00:00Z左右被清理。
- 若想实现“插入后30分钟过期”，需在写入时把字段设为
new Date(Date.now() + 30 * 60 * 1000)，再对这个字段建TTL索引 -
expireAfterSeconds: 0是合法值，表示“字段值即为精确过期时间点”，此时索引等价于{ expireAfterSeconds: 0 } - 后台清理线程默认每60秒扫描一次，因此实际删除可能延迟最多60秒；无法通过配置缩短该间隔
常见误用导致TTL不生效的三个典型场景
TTL索引看似简单，但以下情况会导致文档长期滞留：
- 集合启用了分片，但TTL索引未在分片键上或未包含分片键 —— MongoDB会拒绝创建，但部分旧版本驱动可能静默失败
- 字段存在
null、undefined或非Date值，TTL线程跳过这些文档（不报错，也不清理） - 副本集主节点切换期间，TTL后台线程在新主节点上重启，可能错过一次扫描周期，延迟累积
排查方法：执行db.collection.getIndexes()确认索引存在且expireAfterSeconds值正确；再用db.collection.find({ expireAt: { $lt: new Date() } }).count()估算应删未删量。
比TTL更可控的替代方案：定期运行deleteMany脚本
当需要精确控制清理时机、多条件判断（如“过期且状态为pending”）、或清理逻辑耦合业务规则时，TTL索引反而受限。此时更适合用定时任务+deleteMany：
- 脚本示例：
db.collection.deleteMany({ expireAt: { $lt: new Date() }, status: "pending" }) - 配合
explain("executionStats")确认走的是expireAt上的索引，避免全表扫描 - 在
mongosh中用sleep(1000)分批删除，防止长事务阻塞写入；生产环境建议用find().forEach()加批量deleteMany控制每批数量
TTL索引适合“无脑过期”的日志、会话类数据；一旦涉及状态协同、软删除标记、或审计要求，就得主动接管清理逻辑——毕竟自动不等于可靠，可靠得靠可观察、可中断、可重试的操作。
