ttl索引删除“过慢”是设计使然，并非故障，因其依赖默认每60秒扫描一次的ttlmonitor后台线程，且仅支持顶层date字段、不实时删除；需通过getindexes、findone和serverstatus确认索引状态与数据合规性。
为什么TTL索引删除看起来“过慢”
不是索引坏了，而是它本来就不追求实时性。MongoDB的TTLMonitor后台线程默认每60秒扫描一次TTL索引，每次只删一部分文档——这是设计使然，不是bug。如果你观察到“过期1小时了还没删”，大概率是：expireAfterSeconds从文档createdAt字段时间起算，而非插入时间；或者该字段存的是字符串而非Date类型，导致索引完全不生效。
检查TTL索引是否真在工作
别猜，直接查。用以下三步确认索引状态和数据合规性：
- 运行
db.logs.getIndexes()，确认输出里有"expireAfterSeconds": 604800（比如7天）且键是{"createdAt": 1} - 查一条待过期文档：
db.logs.findOne({ createdAt: { $exists: true } })，确保createdAt字段类型是ISODate，不是字符串或null - 执行
db.runCommand({ serverStatus: 1 }).metrics.ttl，看passes是否递增、deletedDocuments是否增长——如果长期为0，说明根本没触发清理
降低延迟：调整扫描间隔与负载控制
60秒是默认值，但可改。注意：这不是调得越小越好，而是要平衡清理及时性与实例负载。
- 修改扫描频率需重启mongod或动态设置：
db.adminCommand({ setParameter: 1, ttlMonitorEnabled: true })配合db.adminCommand({ setParameter: 1, ttlMonitorSleepSecs: 30 })（最低支持30秒） - 避免在业务高峰期建TTL索引——首次建立可能触发全表扫描，尤其千万级集合；建议提前用
db.logs.deleteMany({ createdAt: { $lt: ISODate("...") } })手动清掉历史过期数据再建索引 - 若集合同时存在多个TTL索引，它们会串行执行；优先保留最核心的一个，其余用应用层定时任务替代
替代方案：什么情况下该放弃TTL索引
TTL索引适合“软过期+低频清理”场景，一旦你遇到这些情况，就得换路子：
- 需要精确到秒级删除（比如支付订单5分钟未支付即关单）→ 改用应用层
setTimeout或消息队列延迟消费 - 过期字段是嵌套路径（如
"meta.createdAt"）→ TTL不支持，必须展平为顶层createdAt字段再建索引 - 集合写入QPS极高（>5k/s），且过期文档占比大 → TTL删除会加剧IO和oplog压力，考虑分库分表+按时间分片归档，或迁移到MongoDB Atlas的
Online Archive自动分层
真正卡住性能的，往往不是TTL本身，而是没意识到它本质是个低频后台批处理——把它当Redis的EXPIRE用，迟早踩坑。
