生存时间 (TTL) 规则何时生效，我们能否控制？

生存时间 (TTL) 规则与控制

生存时间 (TTL) 终究会被应用。这是什么意思？MergeTree 表设置 merge_with_ttl_timeout 用于设置再次执行带删除 TTL 的合并前的最短延迟时间，单位为秒。默认值为 14400 秒 (4 小时) 。但这只是最短延迟，实际触发删除 TTL 合并可能还需要更长时间。你可以使用以下查询查看当前所有 TTL 设置 (例如 merge_with_ttl_timeout) ：

SELECT *
FROM system.merge_tree_settings
WHERE name like '%ttl%'

响应如下：

┌─name───────────────────────────────────────────────────────────┬─value───┬─changed─┬─description────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┬─min──┬─max──┬─readonly─┬─type───┐
│ max_replicated_merges_with_ttl_in_queue                        │ 1       │       0 │ ReplicatedMergeTree 队列中允许同时执行的带 TTL 的 parts 合并任务数量。                                                                                                                    │ ᴺᵁᴸᴸ │ ᴺᵁᴸᴸ │        0 │ UInt64 │
│ max_number_of_merges_with_ttl_in_pool                          │ 2       │       0 │ 当池中带 TTL 的合并条目数超过指定数量时，不再分配新的带 TTL 的合并任务。此设置旨在为常规合并保留空闲线程，避免出现"parts 过多"的问题。                                                  │ ᴺᵁᴸᴸ │ ᴺᵁᴸᴸ │        0 │ UInt64 │
│ merge_tree_clear_old_broken_detached_parts_ttl_timeout_seconds │ 2592000 │       1 │ 若损坏的 detached parts 在后台超过本设置指定的时长未被访问，则将其删除。                                                                                                                  │ ᴺᵁᴸᴸ │ ᴺᵁᴸᴸ │        0 │ UInt64 │
│ merge_with_ttl_timeout                                         │ 14400   │       0 │ 重复执行带删除 TTL 的合并操作所需的最短时间间隔（秒）。                                                                                                                                    │ ᴺᵁᴸᴸ │ ᴺᵁᴸᴸ │        0 │ Int64  │
│ merge_with_recompression_ttl_timeout                           │ 14400   │       0 │ 重复执行带重新压缩 TTL 的合并操作所需的最短时间间隔（秒）。                                                                                                                                │ ᴺᵁᴸᴸ │ ᴺᵁᴸᴸ │        0 │ Int64  │
│ ttl_only_drop_parts                                            │ 0       │       0 │ 仅整体删除已过期的 parts，而不对其进行部分裁剪。                                                                                                                                           │ ᴺᵁᴸᴸ │ ᴺᵁᴸᴸ │        0 │ Bool   │
│ materialize_ttl_recalculate_only                               │ 0       │       0 │ 执行 MATERIALIZE TTL 时仅重新计算 TTL 信息。                                                                                                                                               │ ᴺᵁᴸᴸ │ ᴺᵁᴸᴸ │        0 │ Bool   │
└────────────────────────────────────────────────────────────────┴─────────┴─────────┴────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┴──────┴──────┴──────────┴────────┘

你可以使用 SHOW CREATE TABLE 检查表中是否包含生存时间 (TTL) 规则，以及表中的任何 SETTINGS 是否修改了上述设置的值：

SHOW CREATE TABLE <TableName>

强制应用生存时间 (TTL) 规则

这并不是最理想的解决方案，但你可以显式调用 MATERIALIZE TTL，强制将某个表的所有生存时间 (TTL) 规则物化：

ALTER TABLE my_table
    MATERIALIZE TTL

影响生存时间 (TTL) 的后台线程

你的生存时间 (TTL) 规则之所以可能没有生效，是因为 background pool 中可用的工作线程不足。例如，如果你频繁插入数据，整个 background pool 可能都会被常规合并占满。不过，你可以增大 background pool 的大小。你可以使用以下查询检查当前的 background pool 大小：

SELECT *
FROM system.settings
WHERE name = 'background_pool_size';

返回结果如下所示：

┌─name─────────────────┬─value─┬─changed─┬─description─────────────────────┬─min──┬─max──┬─readonly─┬─type───┬─default─┬─alias_for─┐
│ background_pool_size │ 16    │       0 │ 已废弃，无任何效果。 │ ᴺᵁᴸᴸ │ ᴺᵁᴸᴸ │        0 │ UInt64 │ 16      │           │
└──────────────────────┴───────┴─────────┴─────────────────────────────────┴──────┴──────┴──────────┴────────┴─────────┴───────────┘

请参阅文档，了解如何修改 background_pool_size 设置，其配置如下：

<background_pool_size>16</background_pool_size>

你可以使用以下查询查看当前后台线程池的活动情况：

SELECT *
FROM system.metrics
WHERE metric like 'Background%'

​生存时间 (TTL) 规则与控制

​强制应用生存时间 (TTL) 规则

​影响生存时间 (TTL) 的后台线程

生存时间 (TTL) 规则与控制

强制应用生存时间 (TTL) 规则

影响生存时间 (TTL) 的后台线程