MongoDB 24小时自动删除失效：expire_at设置后仅2分钟过期原因

嘿，这个问题我之前帮好几个开发者排查过，大概率是踩了这几个常见的坑，咱们一步步来分析：

1. 旧的TTL索引没被替换 #

这是最常见的情况！如果你之前在expire_at字段上创建过一个TTL索引（比如测试时设了2分钟过期），后来修改成24小时但没删除旧索引，MongoDB不会自动替换同一个字段上的索引——它会保留旧的那个继续生效。

解决步骤：

• 打开Mongo Shell，执行db.your_collection_name.getIndexes()，找到expire_at对应的索引，查看expireAfterSeconds的值（24小时应该是86400秒）。
• 如果值不对，删除旧索引：db.your_collection_name.dropIndex("expire_at_1")（索引名通常是字段名加_1）。
• 重新启动你的应用，让新的索引创建生效，再用getIndexes()确认expireAfterSeconds是86400。

2. expire_at字段的实际存储值有问题 #

你虽然设置了default: Date.now，但可能存在以下情况：

• 代码里某处手动覆盖了expire_at的值，比如不小心设成了当前时间减去2分钟（比如测试代码没删干净）；
• 你的应用服务器系统时间和MongoDB服务器时间不一致，导致存储的时间比MongoDB的当前时间早；
• Date.now()在你的环境里返回的不是正确的UTC时间（不过这个概率很低）。

解决步骤：

• 插入一个新的测试文档，然后执行db.your_collection_name.findOne()，查看expire_at的具体值；
• 在Mongo Shell里执行new Date()，对比MongoDB服务器的当前时间，看看expire_at是不是确实比当前时间晚24小时；
• 如果时间不对，排查代码中有没有修改expire_at的逻辑，或者同步应用服务器和MongoDB服务器的系统时间。

3. ODM对expires参数的解析出错 #

如果你用的是Mongoose这类ODM，旧版本可能对'24h'这种字符串格式的支持有问题，导致实际转换成的expireAfterSeconds不是86400，而是错误的数值（比如120秒，也就是2分钟）。

解决步骤：

• 把expires: '24h'改成数字形式expires: 86400（因为246060=86400秒）；
• 删除旧索引后重新创建，再用getIndexes()确认参数正确。

4. TTL清理线程的执行频率（次要原因） #

MongoDB的TTL清理线程默认每分钟运行一次，所以即使文档刚好到期，最多可能等1分钟才会被删除。如果你的文档在2分钟后被删，可能是清理线程第一次扫描没命中，第二次才处理，但这个前提是expire_at确实已经过期——所以还是要先排查前面的三个原因。

内容的提问来源于stack exchange，提问作者Mic