Clickhouse源码分析-TTL执行流程

第一种情况：无ttl_only_drop_parts配置

总体示例以及说明

如果没有ttl_only_drop_parts的配置，过期数据的删除（这里是删除，是将过期的数据从这个part删除，并将过期的数据构成一个part，这个过期的part标记为inactive，没过期的变为新part）会在TTL Merge任务中进行。

示例如下，ttl_only_drop_parts = 0：

CREATE TABLE my_table1
(
    `event_time` DateTime,
    `id` UInt64,
    `message` String
)
ENGINE = MergeTree
PARTITION BY toStartOfHour(event_time)
ORDER BY (event_time, id)
TTL event_time + toIntervalMinute(3)
SETTINGS index_granularity = 8192, ttl_only_drop_parts = 0

 插入数据：

INSERT INTO my_table1
SELECT
    now() - INTERVAL intDiv(number, 1000) SECOND AS event_time,  -- 控制时间分布在最近3分钟
    number AS id,
    concat('message_', toString(number)) AS message
FROM numbers(1000000);

这条 SQL 语句的作用是：向 my_table1 表插入 1,000,000 条数据，这些数据的 event_time 字段分布在最近 3 分钟内。

此时100W的数据中，会有两个分区生成：2025-06-30 12:00:00，2025-06-30 13:00:00。

过了一段时间后，由于2025-06-30 12:00:00中已经有部分数据达到过期时间，所以会生成一个1751284800_2_2_1的part，它的active字段为1。

而之前的那个老分区直接设置active字段为0即可，表示为不活跃。

用图解可以表示为：

过一段时间之后：

此时可以看到1751284800_2_2_0中的部分数据也达到了过期时间，之后生成一个名字为1751284800_2_2_1的分区，剩余数据为168000行，相当于过期了1000行。

此部分可以用图解表示为：

再过一段时间可以看到：

此时cleanup后台线程进行了清理后，剩下了最后两个part： 

这里大家可能会有疑问？为什么最后两个part迟迟没有删除呢，它们明明已经到达了最大过期时间了啊？

这个结论放在 <分区到达过期时间却未删除> 这一小节说明。

梳理part的转变

我们也可以从part_log中梳理关于这个表TTL merge：

1️⃣最初插入的数据，ClickHouse 生成了以下两个原始 part：

Time	Event	Part Name	Rows	分区
13:02:48	NewPart	1751284800_2_2_0	831000	2025-06-30 13:00:00
13:02:48	NewPart	1751288400_1_1_0	169000	2025-06-30 12:00:00

这两个 part 加起来就是插入的 1,000,000 行 ✅

2️⃣ ClickHouse 执行 TTL 删除合并1：

Time	Event	Part Name	Rows	类型
13:02:48	MergePartsStart	1751284800_2_2_1	0	开始 TTL 合并
13:02:48	MergeParts	1751284800_2_2_1	11000	TTL 合并后剩下的数据

3️⃣ ClickHouse 执行 TTL 删除合并2：

Time	Event	Part Name	Rows	类型
13:03:00	MergePartsStart	1751288400_1_1_1	0	开始 TTL 合并
13:03:00	MergeParts	1751288400_1_1_1	168000	TTL 合并后剩下的数据

4️⃣清理不活跃的分区

Time	Event	Part Name	Rows	说明
13:12:12	RemovePart	1751284800_2_2_0	831000	被后台clean线程删掉
13:12:12	RemovePart	1751288400_1_1_0	169000	被后台clean线程删掉

分区到达过期时间却未删除

在上面，我们看到了分区达到过期时间，但是却未删除的场景，这是为什么呢？

此时os time：

$ date
Mon Jun 30 01:41:14 PM UTC 2025

这与一个参数有关系：merge_with_ttl_timeout

官网链接如下：Manage Data with TTL (Time-to-live) | ClickHouse Docs

对于后台merge线程选择一个TTL Merge任务（也就是类型为TTLDelete的merge任务）后，它会推迟这个分区向后merge_with_ttl_timeout 毫秒，才能再次选择这个分区。

例如依据上面的示例来说，假如2025-06-30 13:00:00在13:03:00执行，那么下次能选择到分区为2025-06-30 13:00:00的part进行merge，至少在13:03:00 + 4h = 15:03:00 才能发生。

4h为merge_with_ttl_timeout的默认值（转化为小时）。

关键代码位置，更新分区的选择时机：

void MergeTreeDataMergerMutator::updateTTLMergeTimes(const MergeSelectorChoice & merge_choice, const MergeTreeSettingsPtr & settings, time_t current_time)
{chassert(!merge_choice.range.empty());const String & partition_id = merge_choice.range.front().info.getPartitionId();switch (merge_choice.merge_type){case MergeType::Regular:/// Do not update anything for regular merge.return;case MergeType::TTLDelete:next_delete_ttl_merge_times_by_partition[partition_id] = current_time + (*settings)[MergeTreeSetting::merge_with_ttl_timeout];return;case MergeType::TTLRecompress:next_recompress_ttl_merge_times_by_partition[partition_id] = current_time + (*settings)[MergeTreeSetting::merge_with_recompression_ttl_timeout];return;}
}

选择part去merge的调用栈：

chooseMergeFrom()        ->

        MergeSelectorApplier::chooseMergeFrom()        ->

                if 如果有TTL...  then tryChooseTTLMerge()        ->

                        ITTLMergeSelector::select()       ->

                                ITTLMergeSelector::findCenter()

判断位置，是否推迟的逻辑关键函数为needToPostponePartition：

std::optional<ITTLMergeSelector::CenterPosition> ITTLMergeSelector::findCenter(const PartsRanges & parts_ranges) const

{

    assert(!parts_ranges.empty());

    std::optional<CenterPosition> position = std::nullopt;

    for (auto range = parts_ranges.begin(); range != parts_ranges.end(); ++range)

    {

        assert(!range->empty());

        const auto & range_partition = range->front().info.getPartitionId();

        if (needToPostponePartition(range_partition))

            continue;

        for (auto part = range->begin(); part != range->end(); ++part)

        {

            if (!canConsiderPart(*part))

                continue;

            time_t ttl = getTTLForPart(*part);

            if (!ttl || ttl > current_time)

                continue;

            if (!position || ttl < getTTLForPart(*position->center))

                position.emplace(range, part);

        }

    }

    return position;

}

needToPostponePartition内部逻辑为：

bool ITTLMergeSelector::needToPostponePartition(const std::string & partition_id) const

{

    if (auto it = merge_due_times.find(partition_id); it != merge_due_times.end())

        return it->second > current_time;

   

    return false;

}

而这个merge_due_times就是每次merge完之后的调整的next_delete_ttl_merge_times_by_partition。

最后附上TTL执行的部分调用栈：

TODO：调小merge_with_ttl_timeout，验证。

第二种情况： 有ttl_only_drop_parts配置

如果配置了这个参数，ck并不会在某个part中的部分数据达到过期时间时，进行过期数据的删除。而是整个part的数据都达到过期时间时才会进行删除（这里的删除并不是物理删除，而是逻辑上的删除，即将这个part标记为inactive，对应system.parts关于这个part的记录的active字段为0）。

之后MergeTree / ReplicatedMergeTree 的cleanup线程会进行删除（这是物理删除，即删除磁盘中的文件）的动作。

由此可见，不管配没配置这个参数，ck在TTL Merge任务的时候并不会做真正删除过期数据的操作，只是逻辑删除，真正的删除交给后台cleanup线程。

核心代码位置：

执行阶段：

直接跳过：

具体的执行逻辑可以看日志：

部分日志是我手动添加日志的，例如：merge_type = XXX. 这部分。

TODO： 设置system.parts的active字段为0的位置。