> ## 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.

# concurrent_threads_* 服务器设置

> 属于 concurrent_threads_* 自动生成分组的 ClickHouse 服务器设置。

这些设置用于配置 ClickHouse 服务器，由 ClickHouse 源代码自动生成。

## concurrent\_threads\_lazy\_allocation

类型

Bool

默认值

1

无需重启即可更改

Yes

控制如何为查询分配 CPU 插槽。

当 `true` (默认值) 时，查询启动时先占用一个 CPU 插槽，只有当其管道确实产生了更多可并行执行的工作时，才会向调度器申请额外插槽。这样可以避免某个查询预留了多达 `max_threads` 个插槽，却始终只用到其中一部分，从而挤占其他并发查询的资源。此设置同时适用于并发控制以及工作负载的抢占式 CPU 调度器。

当 `false` 时，查询会在启动时一次性申请全部 `max_threads` 插槽。

## concurrent\_threads\_scheduler

类型

String

默认值

max\_min\_fair

无需重启即可更改

Yes

用于指定由 `concurrent_threads_soft_limit_num` 和 `concurrent_threads_soft_limit_ratio_to_cores` 定义的 CPU 插槽调度策略。该算法用于控制有限数量的 CPU 插槽如何在并发查询之间分配。调度器可在运行时更改，无需重启服务器。

可能的值：

* `round_robin` — 每个设置了 `use_concurrency_control` = 1 的查询最多可分配 `max_threads` 个 CPU 插槽。每个线程对应一个插槽。发生争用时，CPU 插槽会按轮询方式分配给各查询。请注意，第一个插槽会无条件分配，这可能导致不公平；当存在大量 `max_threads` = 1 的查询时，还会增加 `max_threads` 较高的查询的延迟。
* `fair_round_robin` — 每个设置了 `use_concurrency_control` = 1 的查询最多可分配 `max_threads - 1` 个 CPU 插槽。这是 `round_robin` 的一种变体，不要求为每个查询的第一个线程分配 CPU 插槽。这样，`max_threads` = 1 的查询不需要任何插槽，因此不会不公平地占用所有插槽。不存在无条件分配的插槽。
* `max_min_fair` — 每个设置了 `use_concurrency_control` = 1 的查询最多可分配 `max_threads - 1` 个 CPU 插槽。它与 `fair_round_robin` 类似，但释放出的插槽始终会分配给当前已获分配插槽数最少的查询。在高超额订阅场景下，也就是大量查询竞争有限 CPU 插槽时，这种方式能提供更好的公平性。运行时间较短的查询不会因为长期运行、并随着时间推移累积了更多插槽的查询而受到不利影响。

## concurrent\_threads\_soft\_limit\_num

类型

UInt64

默认值

0

无需重启即可更改

Yes

允许所有查询使用的最大查询处理线程数，不包括从远程服务器检索数据所使用的线程。这不是硬性限制：即使达到该限制，查询仍至少会获得一个线程来运行。如果后续有更多线程可用，查询在执行过程中还可以扩展到所需的线程数。

> [!NOTE]
>
> 值为 `0` (默认值) 表示不受限制。

## concurrent\_threads\_soft\_limit\_ratio\_to\_cores

类型 UInt64 默认值 2 无需重启即可更改 Yes与 [`concurrent_threads_soft_limit_num`](https://clickhouse.com/docs/zh/reference/settings/server-settings/settings/concurrent-threads#concurrent_threads_soft_limit_num) 相同，但这里是按核心数的比率来设置。