CockroachDB 的 Zone Configs 本身不支持直接设置 TTL（Time-To-Live）字段来自动删除行，它不是像 Redis 或 Cassandra 那样原生提供行级 TTL 的数据库。但你可以通过组合使用 分区表（partitioning）、按时间范围分区 + 自动化任务 和 Zone Configs 的生命周期协同策略，实现可控的数据生命周期管理。
Zone Configs 能管什么？不能管什么？
Zone Configs 主要控制数据的副本放置、容错级别、读写延迟偏好、GC 垃圾回收窗口等物理分布与清理策略，其中最关键的是：
- gc.ttlseconds：定义“已标记为删除但尚未被 GC 清理”的数据在磁盘上保留的最短时间（单位：秒）；它影响的是 MVCC 历史版本的清理时机，不是业务数据的逻辑过期。
- 它不会触发 DELETE 操作，也不会根据某列时间值自动删记录；它只决定旧版本（如 UPDATE/DELETE 产生的历史快照）何时可被安全回收。
- 默认值是 90000（25 小时），生产环境常设为 86400（24 小时）或更长，以支持跨机房故障恢复或长时间备份恢复窗口。
如何模拟“TTL 行为”？用分区 + 定时 DROP
对带时间戳的表（如日志、事件、监控数据），推荐使用 按时间范围分区（PARTITION BY RANGE），再配合外部调度器定期 DROP PARTITION：
- 建表时按
created_at列做月/周分区，例如：PARTITION BY RANGE (created_at) (PARTITION p2024_01 VALUES FROM ('2024-01-01') TO ('2024-02-01'), ...) - 用 cron 或 Airflow 每月初执行
ALTER TABLE events DROP PARTITION p2024_01;—— 这是元数据操作，毫秒级完成，不扫描数据。 - 配合 Zone Config 设置该表的
gc.ttlseconds为较短值（如 3600），确保删除分区后残留 MVCC 版本快速释放空间。
结合备份与 GC 策略保障生命周期安全
单纯 DROP PARTITION 不等于数据彻底消失——若备份中含该分区，且恢复时未跳过，仍可能回流。因此需联动管理：
- 设置
BACKUP命令的AS OF SYSTEM TIME或启用revision_history，避免备份包含即将过期的分区。 - 在 DROP 分区前，确认对应时间段的备份已归档并标记为“可过期”，例如：备份
2024-01数据后 90 天自动清理备份对象。 - 调整集群级 GC 设置（
kv.gc.ttlseconds）要谨慎：太短可能导致跨事务一致性视图丢失；太长则浪费空间。建议按最长恢复点目标（RPO）+ 备份保留期向上取整。
替代方案：应用层 TTL + 物化视图过滤
如果无法改表结构或需更细粒度（如每条记录不同过期时间），可：
- 在业务写入时增加
expires_at TIMESTAMPTZ字段，并创建索引； - 定期运行轻量
DELETE FROM events WHERE expires_at （建议分批，加 LIMIT/OFFSET 或使用 <code>AS OF SYSTEM TIME避免冲突）； - 用物化视图（CockroachDB 23.2+ 支持）预过滤有效数据：
CREATE MATERIALIZED VIEW active_events AS SELECT * FROM events WHERE expires_at > now();，查询走视图即可天然避开过期数据。
