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用，迟早踩坑。