修改ReplacingMergeTree表TTL后数据全被删除的问题求助

我需要将ReplacingMergeTree表的TTL从34天修改为3天，但修改后所有数据都被删除了。

创建表的语句如下：

CREATE TABLE test
(
    `timestamp` DateTime('UTC'),
    `version` DateTime('UTC'),
    `hid` UInt64,
    `port` UInt32,
    `rps` Float32,
    `bps` Float32
)
ENGINE = ReplacingMergeTree(version)
PARTITION BY toYYYYMMDD(timestamp)
ORDER BY (timestamp, hid, port)
TTL timestamp + toIntervalDay(34)
SETTINGS index_granularity = 8192;

我插入了timestamp为2022年4月16日至24日的数据，查询能正常返回这些数据，且system.parts中显示存在20220416至20220424的9个分区。

随后我执行了alter table test remove ttl（该步骤可选，有无此步骤结果一致），再执行alter table test modify ttl timestamp + toIntervalDay(3)，之后表中所有数据消失，查询返回0行。执行Optimize table test final也无法解决问题，请问这是为什么？我哪里操作错了？

核心原因 #

ClickHouse的TTL规则修改后会立即对所有现有数据生效，判断数据是否过期的依据是当前系统时间与TTL表达式计算出的过期时间。你的数据timestamp是2022年4月的，修改TTL为timestamp + 3天后，这些数据的过期时间在2022年4月19日至27日之间，而你执行修改操作的时间远晚于这个区间，所有数据直接被判定为过期并清理。

另外，即使执行remove ttl，已经被标记为过期的数据也无法恢复——TTL的清理标记是不可逆的，remove ttl仅会停止后续的TTL检查，无法回溯恢复已标记删除的数据。

你没有操作错误，但忽略了TTL的生效逻辑 #

TTL修改并非只对新插入数据生效，而是会回溯检查全量现有数据。之前34天的TTL让2022年4月的数据过期时间在2022年5月20日之后，改成3天后过期时间大幅提前，远早于你执行修改的当前时间，因此触发了全量数据清理。

数据恢复的可行方式 #

• 若有备份（比如用BACKUP TABLE生成的备份，或磁盘快照），可直接从备份中恢复数据，这是最稳妥的方式。
• 若数据仍在ClickHouse磁盘目录中（仅被标记待删除但未物理删除），可尝试停止ClickHouse服务，手动复制数据文件到表目录后重启，但这种方式风险极高，不建议生产环境使用。

后续修改TTL的注意事项 #

• 修改前先验证现有数据的过期时间：用SELECT timestamp, timestamp + toIntervalDay(3) AS expire_time FROM test LIMIT 10确认现有数据的过期时间是否晚于当前系统时间，避免误删历史数据。
• 若需保留历史数据，先将历史数据迁移到无TTL或TTL更长的表中，再修改原表TTL。
• 如需对新旧数据设置不同TTL，可考虑使用分区级TTL，针对新分区单独设置规则。

内容的提问来源于stack exchange，提问作者Mauzzz0