> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-detect-table-modification.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

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

> ClickHouse 中的 生存时间 (TTL) 规则最终都会生效，你可以使用 `merge_with_ttl_timeout` 设置来控制其执行时机。了解如何强制应用 TTL，以及如何管理执行 TTL 的后台线程。

<div id="ttl-rules-and-control">
  ## 生存时间 (TTL) 规则与控制
</div>

生存时间 (TTL) 终究会被应用。这是什么意思？`MergeTree` 表设置 [`merge_with_ttl_timeout`](/zh/reference/engines/table-engines/mergetree-family/mergetree#merge_with_ttl_timeout) 用于设置再次执行带删除 TTL 的合并前的最短延迟时间，单位为秒。默认值为 14400 秒 (4 小时) 。但这只是最短延迟，实际触发删除 TTL 合并可能还需要更长时间。

你可以使用以下查询查看当前所有 TTL 设置 (例如 `merge_with_ttl_timeout`) ：

```sql theme={null}
SELECT *
FROM system.merge_tree_settings
WHERE name like '%ttl%'
```

响应如下：

```response theme={null}
┌─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` 是否修改了上述设置的值：

```sql theme={null}
SHOW CREATE TABLE <TableName>
```

<div id="force-a-ttl-rule-to-be-applied">
  ## 强制应用生存时间 (TTL) 规则
</div>

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

```sql theme={null}
ALTER TABLE my_table
    MATERIALIZE TTL
```

<div id="background-threads-affecting-ttl">
  ## 影响生存时间 (TTL) 的后台线程
</div>

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

你可以使用以下查询检查当前的 `background pool` 大小：

```sql theme={null}
SELECT *
FROM system.settings
WHERE name = 'background_pool_size';
```

返回结果如下所示：

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

请参阅文档，了解如何修改 [`background_pool_size` 设置](/zh/reference/settings/server-settings/settings#background_pool_size)，其配置如下：

```xml theme={null}
<background_pool_size>16</background_pool_size>
```

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

```sql theme={null}
SELECT *
FROM system.metrics
WHERE metric like 'Background%'
```