数据生命周期与 TTL 是什么
过期数据主动清理是控制成本的常规手段：MongoDB 用 TTL 索引由后台周期删除，Elasticsearch 用 ILM 分阶段下沉与删除，ClickHouse 的 TTL 在合并时执行并支持冷热分层，Redis 键过期采用惰性加定期清理。清理策略要与备份和合规要求对齐：主库删掉但备份里仍保留的周期如果不一致，审计时会出现两边对不上的情况。
基本信息
| MongoDB | TTL 索引由后台线程周期扫描删除 |
|---|---|
| Elasticsearch | ILM 分阶段下沉与删除 |
| ClickHouse | TTL 在合并时执行，支持分层到不同卷 |
| Redis | 惰性删除加定期抽样清理 |
| 计时精度 | 以上机制都是近似值，不是精确定时器 |
典型使用场景
- 会话数据清理：给会话集合加 TTL 索引自动过期
- 日志保留：按 ILM 策略把旧索引下沉并删除
- 冷热分层：ClickHouse 把旧数据移到冷卷后再删除
- 缓存过期：用 Redis 过期时间控制内存占用
- 合规对齐：核对线上清理周期与备份保留周期
各库配置示例
各库配置示例
# MongoDB：创建 TTL 索引（后台线程周期扫描）
db.sessions.createIndex({ createdAt: 1 }, { expireAfterSeconds: 3600 })
# Redis：设置键过期
redis-cli EXPIRE session:1 1800
# InfluxDB：按桶的保留期自动清理
influx bucket update -n metrics -r 30d清理机制对照
| 系统 | 写法 | 执行时机 |
|---|---|---|
| MongoDB | expireAfterSeconds | 后台周期扫描 |
| Elasticsearch | ILM 的 delete 阶段 | 周期任务评估 |
| ClickHouse | MODIFY TTL ... DELETE | 合并时执行 |
| Redis | EXPIRE | 惰性加定期清理 |
| InfluxDB | bucket retention | 后台按桶清理 |
清理计时都是近似值：TTL 线程周期扫描、ClickHouse 依赖合并、ILM 由周期任务评估，都不适合当作精确的定时删除器。
大批数据在同一时间点集中到期会造成删除与合并压力，策略里应给时间加抖动。
备份保留周期要与线上清理对齐，主库已删除而备份仍留有合规数据时，两边口径会互相矛盾。
对合规要求较强的数据，清理动作本身最好留痕：谁在什么时候按什么策略删除了哪些范围，事后审计才有依据。
TTL 索引只针对单个日期类型字段生效，字段里混入非日期类型时该文档不会被清理，写入前要保证类型一致。