Set up docs MCP生存时间 (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 │ How many tasks of merging parts with TTL are allowed simultaneously in ReplicatedMergeTree queue. │ ᴺᵁᴸᴸ │ ᴺᵁᴸᴸ │ 0 │ UInt64 │
│ max_number_of_merges_with_ttl_in_pool │ 2 │ 0 │ When there is more than specified number of merges with TTL entries in pool, do not assign new merge with TTL. This is to leave free threads for regular merges and avoid "Too many parts" │ ᴺᵁᴸᴸ │ ᴺᵁᴸᴸ │ 0 │ UInt64 │
│ merge_tree_clear_old_broken_detached_parts_ttl_timeout_seconds │ 2592000 │ 1 │ Remove old broken detached parts in the background if they remained intouched for a specified by this setting period of time. │ ᴺᵁᴸᴸ │ ᴺᵁᴸᴸ │ 0 │ UInt64 │
│ merge_with_ttl_timeout │ 14400 │ 0 │ Minimal time in seconds, when merge with delete TTL can be repeated. │ ᴺᵁᴸᴸ │ ᴺᵁᴸᴸ │ 0 │ Int64 │
│ merge_with_recompression_ttl_timeout │ 14400 │ 0 │ Minimal time in seconds, when merge with recompression TTL can be repeated. │ ᴺᵁᴸᴸ │ ᴺᵁᴸᴸ │ 0 │ Int64 │
│ ttl_only_drop_parts │ 0 │ 0 │ Only drop altogether the expired parts and not partially prune them. │ ᴺᵁᴸᴸ │ ᴺᵁᴸᴸ │ 0 │ Bool │
│ materialize_ttl_recalculate_only │ 0 │ 0 │ Only recalculate ttl info when MATERIALIZE 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 │ Obsolete setting, does nothing. │ ᴺᵁᴸᴸ │ ᴺᵁᴸᴸ │ 0 │ UInt64 │ 16 │ │
└──────────────────────┴───────┴─────────┴─────────────────────────────────┴──────┴──────┴──────────┴────────┴─────────┴───────────┘请参阅文档，了解如何修改 background_pool_size 设置，其配置如下：
<background_pool_size>16</background_pool_size>你可以使用以下查询查看当前后台线程池的活动情况：
SELECT *
FROM system.metrics
WHERE metric like 'Background%'