ClickHouse TTL 策略自动删除之前先算合并成本一、TTL 不是免费清理ClickHouse 的 TTL 可以自动删除、移动或聚合数据看起来很适合日志和明细数据生命周期管理。但 TTL 依赖后台 merge 生效数据不会到期瞬间消失。策略写得太激进反而会增加合并压力影响查询和写入。自动删除之前要先算合并成本。二、明确生命周期目标flowchart TD A[数据写入] -- B[热数据] B -- C[温数据] C -- D[冷数据] D -- E[删除或归档]不同阶段的存储和查询需求不同。热数据追求查询速度冷数据追求成本过期数据追求可控删除。TTL 规则要服务这些目标而不是只写一个保留天数。ALTER TABLE events MODIFY TTL event_time INTERVAL 30 DAY DELETE;这条规则简单但是否适合要看分区、merge 频率和查询模式。三、分区设计影响 TTLTTL 和分区粒度密切相关。如果按月分区却要求保留 7 天后台需要在分区内部做大量清理。若按天分区删除过期分区可能更直接但分区过细又会增加元数据和小文件压力。ttl_partition_check: retention_days: 30 partition_granularity: daily merge_pressure: monitored small_parts_limit: definedTTL 设计要和分区设计一起看。只改 TTL不看 parts 数量和 merge 队列很容易埋雷。四、监控后台合并TTL 生效依赖 merge必须监控后台任务。parts 数量增长、merge 队列堆积、磁盘写入升高都可能说明 TTL 策略过重。SELECT database, table, elapsed, progress FROM system.merges WHERE is_mutation 0;还要观察查询性能。TTL merge 和正常查询争资源时用户看到的是查询变慢而不是“TTL 正在工作”。最后TTL 变更要灰度。先在小表或部分租户上验证保留策略、空间回收速度和 merge 成本再推广到大表。自动化生命周期管理也需要变更流程。如果 TTL 同时承担冷热迁移和删除更要拆开观察。移动到低成本磁盘后查询延迟可能上升删除过期数据时空间回收又受 merge 节奏影响。两个目标混在一起很难判断到底哪里出了问题。ttl_observability: expired_rows_estimated: true bytes_reclaimed: true merge_queue_length: true cold_tier_query_latency: true还要关注副本一致性。集群中不同副本 merge 进度可能不同短时间内空间占用和查询表现不一致。监控要按副本展开而不是只看表级汇总。最后TTL 规则变更前要确认合规要求。日志、审计和交易类数据可能有最低保留期限技术上能删不代表业务上能删。如果表上还有物化视图或下游同步也要确认 TTL 删除后的传播行为。源表数据过期后下游汇总表是否仍需保留重算任务是否依赖明细数据这些都要提前对齐。ttl_downstream_check: materialized_view_impact: true export_job_impact: true backfill_dependency: true五、总结ClickHouse TTL 策略要结合生命周期目标、分区粒度、parts 数量、merge 队列和查询影响。自动删除不是免费午餐。TTL 写下去之后后台合并会替你付账。