> ## Documentation Index
> Fetch the complete documentation index at: https://clickhouse.com/docs/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`](/docs/zh/reference/settings/merge-tree-settings#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 │ 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` 是否修改了上述设置的值：

```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` 设置](/docs/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%'
```