Clickhouse 的配置太多且难以理解，花了两天逐步理解每个配置的作用
并逐段机翻了一下注释，并增加了如何配置的建议
<!--
NOTE: User and query level settings are set up in "users.xml" file.
If you have accidentally specified user-level settings here, server won't start.
You can either move the settings to the right place inside "users.xml" file
or add <skip_check_for_incorrect_settings>1</skip_check_for_incorrect_settings> here.
提示：
不要把该配置在 users.xml 里面的标签配置到 config.xml 或其他类型的配置文件，只能在同类型的(主子文件)中配置，否则 Clickhouse 会启动失败！
如果配错了，而又不想挪动配置，可以使用这个标签跳过检查，skip_check_for_incorrect_settings，不推荐用于生产环境，因为它可能会隐藏配置错误。
-->
<!--
注意：
Clickhouse 的配置标签顺序比较绕，同类型的配置标签可能并不是有序的。比如：第 N 行是配置某个文件path，第 N+M 行又有配置另一个文件path
-->
<clickhouse>
<!--
引入配置，将多个配置文件组织在一起，从而简化主配置文件的结构，并实现配置的模块化管理
ClickHouse 服务器在启动时会读取并解析主配置文件中的 <include_from> 标签，加载指定路径下的 XML 文件内容作为配置的一部分。这使得可以将特定的配置分离到单独的文件中，例如集群配置、安全配置等。
如果主配置文件与包含的文件中存在相同的标签，ClickHouse 会根据以下规则进行解析：
[[ 顺序解析，并且，后解析的配置会覆盖先前解析的相同标签的配置！ ]]
1、如果 include_from 标签在最上方，解析时会先解析引入文件(子文件)中的内容，完毕后，继续往下执行(主文件)，也就是说，如果有相同标签配置，这种情况下主文件会覆盖子文件的配置
2、如果 include_from 标签在最下方，解析时会顺序解析(主文件)，如果有相同配置，最后解析(子文件)时，会将(主文件)的配置覆盖
总结：
1、解析的顺序决定覆盖的优先级：后解析的配置项会覆盖先解析的配置项。
2、无论配置在主文件还是包含文件中，最终生效的配置是最后被解析到的配置。
建议：
1、如果有过多的自定义配置，可以拆分为多个子文件，主文件只引入所有子文件，不保留任何配置。
2、如果改动的配置较少，可以不使用子文件，全部在当前文件改动。
-->
<include_from>/etc/clickhouse-server/config.d/metrika.xml</include_from>
<!-- ============================================================= 日志配置 ================================================================ -->
<logger>
<!-- Possible levels [1]: 设置日志记录的详细级别:
- none (关闭日志记录)
- fatal 记录致命错误
- critical 记录严重错误
- error
- warning
- notice 记录通知信息
- information 记录详细信息
- debug
- trace 记录所有日志信息，包括详细的调试信息
- test (不适合生产使用)
[1]: https://github.com/pocoproject/poco/blob/poco-1.9.4-release/Foundation/include/Poco/Logger.h#L105-L114
-->
<level>trace</level>
<!-- 普通日志目录 -->
<log>/data/clickhouse/log/clickhouse-server.log</log>
<!-- error 日志目录 -->
<errorlog>/data/clickhouse/log/clickhouse-server-err.log</errorlog>
<!-- 建议：根据磁盘空间和日志生成量，调整日志文件大小和数量。对于大多数生产环境，1GB 的日志文件大小和 10 个文件的保留数量是合适的，但可以根据实际需求进行调整。 -->
<!-- 每个日志文件的最大大小，设置为 1000M 表示每个日志文件最大 1GB。 -->
<size>1000M</size>
<!-- 保留的日志文件数量，设置为 10 表示保留 10 个日志文件。 -->
<count>10</count>
<!--
含义：控制是否将日志输出到控制台。默认行为是自动检测，如果不是守护进程模式并且是终端（TTY），则会输出到控制台。
建议：一般情况下，建议注释掉或删除此配置，以避免不必要的控制台输出。日志通常写入文件，而不是控制台。
-->
<!-- <console>1</console> --> <!-- Default behavior is autodetection (log to console if not daemon mode and is tty) -->
<!--
每级覆盖（旧版）：
例如，要禁止记录 ConfigReloader，您可以使用 levels.logger 是保留的，见下文。
含义：可以针对不同的日志记录器设置特定的日志级别。例如，可以选择对某些日志记录器禁用日志。
建议：一般情况下，保持默认配置。如果有特定的需求，可以针对性地配置日志级别。
-->
<!--
<levels>
<ConfigReloader>none</ConfigReloader>
</levels>
-->
<!--
每级覆盖（新版）：
例如，要禁止默认用户的 RBAC 日志记录，您可以使用：
（但请注意，即使在小幅升级之后，记录器名称也可能会因版本而异）
-->
<!--
<levels>
<logger>
<name>ContextAccess (default)</name>
<level>none</level>
</logger>
<logger>
<name>DatabaseOrdinary (test)</name>
<level>none</level>
</logger>
</levels>
-->
<!--
结构化日志格式：
可以指定日志格式（目前仅支持 JSON）。在这种情况下，将打印控制台日志，以指定格式，如 JSON。
{"date_time":"1650918987.180175","thread_name":"#1","thread_id":"254545","level":"Trace","query_id":"","logger_name":"BaseDaemon","message":"Received signal 2","source_file":"../base/daemon/BaseDaemon.cpp; virtual void SignalListener::run()","source_line":"192"} 要启用 JSON 日志记录支持，请取消注释下面的整个 <formatting> 标记。
a) 您可以通过更改 <names> 标签内的标签值下的值来修改键名称。
例如，要将 DATE_TIME 更改为 MY_DATE_TIME，您可以执行以下操作：
<date_time>MY_DATE_TIME</date_time>
b) 您可以阻止不需要的日志属性出现在日志中。为此，您只需注释掉即可（推荐），该文件中的该属性。
例如，如果您不希望日志打印query_id，则可以仅注释掉<query_id>标签。
但是，如果注释掉 <names> 下的所有标签，程序将打印默认值
-->
<!-- <formatting>
<type>json</type>
<names>
<date_time>date_time</date_time>
<thread_name>thread_name</thread_name>
<thread_id>thread_id</thread_id>
<level>level</level>
<query_id>query_id</query_id>
<logger_name>logger_name</logger_name>
<message>message</message>
<source_file>source_file</source_file>
<source_line>source_line</source_line>
</names>
</formatting> -->
</logger>
<!-- ============================================================= 端口及访问相关配置 ================================================================ -->
<!-- 在选项请求中添加响应头。 OPTIONS 方法用于 CORS 预检请求 -->
<!-- 默认情况下它是关闭的。接下来的标头对于 CORS 是必需的.-->
<!--
Access-Control-Allow-Origin
含义：指定哪些域可以访问你的资源。* 表示允许所有域访问。如果需要限制特定的域，可以将 * 替换为域名，例如 https://example.com。
建议：在生产环境中，应该替换为特定的域名，以增强安全性。
Access-Control-Allow-Headers
含义：指定允许的请求头字段。origin 和 x-requested-with 是常见的头部字段，通常用于标识请求源和类型。
建议：根据你的应用需求，添加或调整允许的请求头字段。如果需要支持更多头字段，请在此列出它们。
Access-Control-Allow-Methods
含义：指定允许的 HTTP 方法。POST, GET, 和 OPTIONS 是常用的方法，OPTIONS 用于 CORS 预检请求。
建议：根据实际使用的 HTTP 方法进行配置。如果支持其他方法（如 PUT, DELETE），请在此添加。
Access-Control-Max-Age
含义：指定预检请求的结果在多长时间内有效（以秒为单位）。86400 秒等于 24 小时。
建议：可以根据实际需求调整。如果希望减少预检请求的频率，可以增加此值，但也可能导致更长时间的缓存结果。
配置建议
安全性：在生产环境中，建议将 Access-Control-Allow-Origin 的值设置为特定的域名，而不是 *，以防止未经授权的域访问你的资源。
灵活性：根据实际需求，调整 Access-Control-Allow-Headers 和 Access-Control-Allow-Methods 的内容，以支持所需的请求头和方法。
性能：设置适当的 Access-Control-Max-Age 值，可以减少预检请求的频率，但要权衡缓存时间与数据的新鲜性。
-->
<!-- http_options_response>
<header>
<name>Access-Control-Allow-Origin</name>
<value>*</value>
</header>
<header>
<name>Access-Control-Allow-Headers</name>
<value>origin, x-requested-with</value>
</header>
<header>
<name>Access-Control-Allow-Methods</name>
<value>POST, GET, OPTIONS</value>
</header>
<header>
<name>Access-Control-Max-Age</name>
<value>86400</value>
</header>
</http_options_response -->
<!-- 这是将在 clickhouse-client 中显示的名称。默认情况下，任何带有“生产”的内容都会在查询提示中以红色突出显示。 -->
<!--display_name>production</display_name-->
<!-- HTTP API 的端口。另请参阅“https_port”以了解安全连接。ODBC 和 JDBC 驱动程序（DataGrip、Dbeaver 等）也使用此接口，以及大多数 Web 界面（嵌入式 UI、Grafana、Redash 等）。 -->
<http_port>8123</http_port>
<!-- 通过本机协议与以下设备交互的端口：
- clickhouse-client 和其他原生 ClickHouse 工具（clickhouse-benchmark、clickhouse-copier）；
- clickhouse-server 与其他 clickhouse-servers 一起进行分布式查询处理；
- ClickHouse驱动程序和应用程序支持本机协议，该协议也被非正式地称为“TCP 协议”）；
另请参阅“tcp_port_secure”以了解安全连接。
含义：用于 ClickHouse 的原生协议通信的端口。包括与 ClickHouse 客户端、其他 ClickHouse 服务器、以及支持原生协议的应用程序进行交互。
建议：确保此端口没有被其他服务占用。可以根据需求调整，但要确保网络安全策略允许这个端口的流量。
-->
<tcp_port>9992</tcp_port>
<!--
MySQL 兼容端口
含义：与 MySQL 协议的兼容性。对于连接到此端口的应用程序，ClickHouse 将伪装成 MySQL。
建议：如果需要兼容 MySQL 的应用程序连接此端口，确保没有其他服务占用此端口。如果不需要此功能，可以将其注释掉或删除。
-->
<mysql_port>9004</mysql_port>
<!--
PostgreSQL 兼容端口
含义：与 PostgreSQL 协议的兼容性。对于连接到此端口的应用程序，ClickHouse 将假装是 PostgreSQL。
建议：如果需要兼容 PostgreSQL 的应用程序连接此端口，确保没有其他服务占用此端口。如果不需要此功能，可以将其注释掉或删除。
-->
<postgresql_port>9005</postgresql_port>
<!--
HTTPS 端口
含义：用于 HTTP API 的安全连接（TLS/HTTPS）端口。必须配置证书才能启用此接口
建议：如果需要通过 HTTPS 保护 HTTP API，启用此端口并配置 SSL/TLS 证书。如果不需要 HTTPS，可以保持注释状态。
-->
<!-- <https_port>8443</https_port> -->
<!--
安全 TCP 端口
含义：用于原生接口的安全连接（TLS）的端口。需要配置证书来启用此接口。
建议：如果需要通过 TLS 保护 TCP 连接，启用此端口并配置 SSL/TLS 证书。如果不需要安全连接，可以保持注释状态。
-->
<!-- <tcp_port_secure>9440</tcp_port_secure> -->
<!--
带 PROXYv1 协议的 TCP 端口
含义：用于与支持 PROXYv1 协议的代理服务器进行通信的端口。PROXYv1 头部会在每个连接中发送，ClickHouse 会从标头中提取有关代理转发的客户端地址的信息。
建议：如果使用代理服务器并需要 PROXYv1 协议支持，启用此端口。如果不需要此功能，可以保持注释状态。
-->
<!-- <tcp_with_proxy_port>9011</tcp_with_proxy_port> -->
<!--
副本通信端口
含义：用于副本之间通信的端口。用于数据交换。它提供服务器之间的低级数据访问。不应从不受信任的网络访问此端口，应该只在可信网络中开放。
建议：确保此端口只在受信任的网络中开放，并采取适当的安全措施，防止未授权访问。 另请参见"interserver_https_port"、"interserver_http_credentials"。
-->
<interserver_http_port>9009</interserver_http_port>
<!--
TLS 加密的副本通信端口
含义：使用 TLS 在副本之间进行通信的端口。用于副本间通信的 TLS 加密端口。要启用此端口，需要配置 SSL/TLS 证书。另请参阅“interserver_http_credentials”
建议：如果你希望在副本间通信中使用 TLS 加密，可以启用此端口并确保配置了合适的 SSL/TLS 证书。特别是在不信任的网络中进行副本间通信时，建议启用此配置。
-->
<!-- <interserver_https_port>9010</interserver_https_port> -->
<!--
副本间通信的主机名
含义：其他副本用于请求当前服务器的主机名。如果未指定，将类似于执行 hostname -f 命令自动确定主机名。此设置可用于在服务器连接到多个网络接口时，将复制操作切换到另一个网络接口。（服务器可能通过多个地址连接到多个网络）
建议：如果你的服务器具有多个网络接口或主机名配置比较复杂，可以明确指定此主机名以确保副本间通信的稳定性。否则，可以保持注释状态，使用系统自动确定的主机名。
-->
<!--
<interserver_http_host>example.clickhouse.com</interserver_http_host>
-->
<!--
副本间通信认证凭证
含义：您可以指定用于副本之间身份验证的凭据。当可从不受信任的网络访问 interserver_https_port 时，这是必需的，还建议避免来自网络中可能受损的服务的 SSRF 攻击。
建议：如果启用了 interserver_https_port 或者你的 ClickHouse 副本通信端口暴露在不信任的网络上，建议配置强密码的凭证以提高安全性。如果通信只发生在内部受信网络中，且通信端口没有暴露，可以选择不启用此配置。
-->
<!--<interserver_http_credentials>
<user>interserver</user>
<password></password>
</interserver_http_credentials>-->
<!-- 监听指定地址。
如果您想接受来自任何地方的 IPv4 和 IPv6 连接，请使用 ::（通配符 IPv6 地址）。
如果您从通配符地址打开连接，请确保至少应用以下措施之一：
- 服务器受防火墙保护，无法从不受信任的网络访问；
- 所有用户都仅限于网络地址的子集（请参阅 users.xml）；
- 所有用户都有强密码，只能访问安全 (TLS) 接口，或者只能通过 TLS 接口进行连接。
- 没有密码的用户具有只读访问权限。
含义：此配置项定义 ClickHouse 服务器监听的地址。:: 是一个通配符地址，表示服务器将接受来自所有 IPv4 和 IPv6 地址的连接。
建议：默认情况下，使用 :: 可以让服务器监听所有地址，但要确保你的服务器受到防火墙保护，避免从不信任的网络访问。也可以通过 users.xml 配置文件限制用户访问的网络地址，或确保所有用户使用强密码。
如果不需要监听所有地址，可以指定一个具体的地址，如 127.0.0.1（仅本地）或特定的网络接口地址。
另请参阅：https://www.shodan.io/search?query=clickhouse
-->
<listen_host>::</listen_host>
<!--
含义：0.0.0.0 表示监听所有可用的 IPv4 地址。这意味着服务器将接受来自所有 IPv4 地址的连接。
建议：如果你的服务器只需要处理 IPv4 请求，并且需要从多个网络接口接受连接，可以启用此选项。否则，可以将此配置保持注释状态，选择其他合适的监听地址。
-->
<!-- <listen_host>0.0.0.0</listen_host> -->
<!--
默认值 - 尝试侦听 IPv4 和 IPv6 上的本地主机。
含义：::1 是本地主机的 IPv6 地址，而 127.0.0.1 是本地主机的 IPv4 地址。这些配置用于指定服务器仅监听本地回环接口上的连接。
建议：如果你的 ClickHouse 服务器只需要处理来自本地的请求，可以启用这些选项。通常在开发环境或需要更高安全性的场景中使用。
-->
<!--
<listen_host>::1</listen_host>
<listen_host>127.0.0.1</listen_host>
-->
<!--
副本间通信的监听地址
含义：指定副本间通信的监听地址，默认与 <listen_host> 配置相同。
建议：除非你的副本间通信需要通过不同的网络接口，否则可以保持注释状态，让它与 <listen_host> 一致。如果要分离网络流量，可以配置特定的地址。
-->
<!-- <interserver_listen_host>::</interserver_listen_host> -->
<!-- Listen host for communication between replicas. Used for data exchange -->
<!-- Default values - equal to listen_host -->
<!--
监听时的错误容忍
含义：在尝试监听 IPv6 或 IPv4 网络不可用时，是否让服务器继续运行。如果设置为 0，则如果网络不可用，服务器会停止运行。
建议：在大多数生产环境中，建议保持默认值 0，确保所有配置的网络都可用。如果在开发环境或特定的容错场景中，可以将其设置为 1 以继续运行。
-->
<!-- <listen_try>0</listen_try> -->
<!--
端口复用
含义：允许多个服务器在同一地址和端口上监听。通常不推荐这样做，因为可能会导致冲突。
建议：除非你有明确的需求，比如在特定的负载均衡场景下使用此功能，否则建议保持为 0，即不启用端口复用。
-->
<!-- <listen_reuse_port>0</listen_reuse_port> -->
<!--
监听队列长度
含义：定义操作系统为新的传入连接请求维护的队列长度。如果有大量的并发连接请求，此值可以影响服务器的性能。
建议：4096 是一个相对较高的值，适用于高并发场景。如果你的 ClickHouse 服务器处理大量并发请求，可以考虑保留此值。如果并发量较小，可以根据需要调整。
-->
<!-- <listen_backlog>4096</listen_backlog> -->
<!--
最大连接数
含义：定义服务器可以同时处理的最大连接数。这个配置影响服务器的性能和资源使用。
建议：4096 是一个常见的配置，适用于大多数生产环境。如果你发现服务器的负载过高，可能需要根据资源（如 CPU 和内存）情况适当调整此值。
-->
<max_connections>4096</max_connections>
<!--
HTTP 连接保持时间
含义：用于 HTTP 1.1 中的 Connection: keep-alive 选项，定义连接在空闲状态下保持活动的时间（秒）。这有助于减少创建新连接的开销。
建议：3 秒是一个合理的设置。如果你的应用程序需要长时间保持连接，可以适当增加这个值。如果希望减少资源占用，可以缩短这个时间。
-->
<keep_alive_timeout>3</keep_alive_timeout>
<!-- ============================================================= 协议及安全相关配置 ================================================================ -->
<!-- gRPC 协议（API 参见 src/Server/grpc_protos/clickhouse_grpc.proto） -->
<!--
gRPC 端口
含义：指定 gRPC 服务监听的端口。如果要启用 gRPC 服务，需要取消注释并设置合适的端口号。
建议：如果你需要通过 gRPC 协议与 ClickHouse 交互，建议配置并启用这个端口。确保选择一个未被占用的端口号，并在防火墙规则中开放。
-->
<!-- <grpc_port>9100</grpc_port> -->
<grpc>
<!--
是否启用 SSL
含义：控制 gRPC 通信是否使用 SSL/TLS 加密。如果设置为 true，gRPC 通信将会加密。
建议：如果 gRPC 服务在不安全的网络中运行，建议启用 SSL（设置为 true），并配置证书文件。否则，可以保持 false。
-->
<enable_ssl>false</enable_ssl>
<!-- 以下两个文件只有enable_ss使用
SSL 证书文件（<ssl_cert_file>）与密钥文件（<ssl_key_file>）
含义：当 SSL 启用时，这些选项指定服务器使用的 SSL 证书文件和对应的私钥文件的路径。
建议：在启用 SSL 的情况下，需要配置这两个文件的路径，确保路径正确且证书和密钥文件有效。
-->
<ssl_cert_file>/path/to/ssl_cert_file</ssl_cert_file>
<ssl_key_file>/path/to/ssl_key_file</ssl_key_file>
<!--
客户端证书验证
含义：决定服务器是否要求客户端提供证书进行身份验证。如果设置为 true，服务器将要求客户端提供证书，增加安全性。
建议：在高安全性环境下，建议启用客户端证书验证（设置为 true）。否则，可以保持为 false。
-->
<ssl_require_client_auth>false</ssl_require_client_auth>
<!--
客户端 CA 证书文件（只有 ssl_require_client_auth=1 使用以下文件）
含义：如果启用了客户端证书验证（<ssl_require_client_auth> 设置为 true），此选项指定用于验证客户端证书的 CA 证书文件路径。
建议：在启用客户端验证的情况下，需要正确配置此文件路径，确保 CA 证书有效。
-->
<ssl_ca_cert_file>/path/to/ssl_ca_cert_file</ssl_ca_cert_file>
<!-- 默认传输压缩类型（可以由客户端覆盖，请参阅 QueryInfo 中的 Transport_compression_type 字段）。支持的算法：none、deflate、gzip、stream_gzip
含义：指定 gRPC 传输中的压缩算法。支持的算法包括 none（无压缩）、deflate、gzip 和 stream_gzip。
建议：默认 none 适用于大多数情况。如果你需要减少带宽占用，可以选择合适的压缩算法，比如 gzip。
-->
<transport_compression_type>none</transport_compression_type>
<!--
传输压缩级别
含义：定义传输压缩的级别，范围为 0 到 3。数字越大，压缩效果越好，但可能增加 CPU 开销。
建议：0 表示不压缩。如果选择了压缩算法，可以根据需要调整压缩级别。建议在压缩与性能之间找到平衡点。
-->
<transport_compression_level>0</transport_compression_level>
<!-- 发送/接收消息大小限制（以字节为单位）。 -1表示无限制
含义：设置 gRPC 传输的最大消息大小，单位为字节。-1 表示不限制消息大小。
建议：默认 -1 适用于大多数场景。如果你的应用程序有特定的消息大小要求，可以设置合适的限制值。
-->
<max_send_message_size>-1</max_send_message_size>
<max_receive_message_size>-1</max_receive_message_size>
<!-- 如果您想要非常详细的日志，请启用
含义：控制是否启用详细的 gRPC 日志。详细日志可以帮助调试，但可能会生成大量日志数据。
建议：在生产环境中，建议保持 false 以避免过多日志。如果需要调试，可以暂时设置为 true。
-->
<verbose_logs>false</verbose_logs>
</grpc>
<!-- Used with https_port and tcp_port_secure. Full ssl options list: https://github.com/ClickHouse-Extras/poco/blob/master/NetSSL_OpenSSL/include/Poco/Net/SSLManager.h#L71 -->
<openSSL>
<server> <!-- 用于https服务器和安全的tcp端口 -->
<!-- openssl req -subj "/CN=localhost" -new -newkey rsa:2048 -days 365 -nodes -x509 -keyout /etc/clickhouse-server/server.key -out /etc/clickhouse-server/server.crt -->
<!--
证书文件和私钥文件
含义：指定服务器使用的 SSL 证书文件和对应的私钥文件。这两个文件用于加密通信。
建议：如果你启用了 HTTPS 或者安全的 TCP 端口（tcp_port_secure），需要将这两个选项的注释取消，并配置证书文件路径。确保文件路径正确且证书有效。
-->
<!--
<certificateFile>/etc/clickhouse-server/server.crt</certificateFile>
<privateKeyFile>/etc/clickhouse-server/server.key</privateKeyFile>
-->
<!-- Diffie-Hellman 参数文件，dhparams 是可选的。您可以删除 <dhParamsFile> 元素。
要生成 dhparams，请使用以下命令： openssl dhparam -out /etc/clickhouse-server/dhparam.pem 4096 仅支持带有 BEGIN DH PARAMETERS 的文件格式。
含义：指定 Diffie-Hellman 参数文件，用于加强 SSL/TLS 的安全性。这是可选配置。
建议：除非你有特定的安全需求，否则可以忽略此配置。如果需要，确保参数文件存在并有效。
-->
<!-- <dhParamsFile>/etc/clickhouse-server/dhparam.pem</dhParamsFile>-->
<!--
验证模式
含义：控制服务器如何验证客户端证书。如果设置为 none，则不要求客户端提供证书。
建议：大多数情况下，保持 none 是合适的。如果需要更高的安全性，可以根据需求调整为 relaxed 或 strict。
-->
<verificationMode>none</verificationMode>
<!--
加载默认 CA 文件
含义：指定是否加载系统默认的 CA 证书文件，用于验证客户端证书。
建议：保持为 true，以确保服务器可以验证从受信任 CA 签发的客户端证书。
-->
<loadDefaultCAFile>true</loadDefaultCAFile>
<!--
会话缓存
含义：启用 SSL 会话缓存，以提高重复连接的性能。
建议：建议启用以提高性能。
-->
<cacheSessions>true</cacheSessions>
<!--
禁用旧协议
含义：禁用不安全的 SSLv2 和 SSLv3 协议。
建议：保持该配置，禁用旧协议以确保安全。
-->
<disableProtocols>sslv2,sslv3</disableProtocols>
<!--
优先使用服务器的密码套件
含义：优先使用服务器配置的密码套件，而不是客户端的。
建议：保持为 true，以确保使用安全性较高的密码套件。
-->
<preferServerCiphers>true</preferServerCiphers>
<!-- 无效证书处理 -->
<invalidCertificateHandler>
<!--
含义：指定如何处理无效的客户端证书。服务器通常拒绝无效证书。
建议：保持为 RejectCertificateHandler，以确保无效证书被拒绝。
-->
<name>RejectCertificateHandler</name>
</invalidCertificateHandler>
</server>
<!--
用于连接到 https 字典源和安全的 Zookeeper 通信，这些配置项与服务器端类似，建议保持默认配置
-->
<client>
<!--
默认 CA 文件加载
含义：同样适用于客户端，用于验证服务器证书。
建议：保持为 true，确保客户端能够验证从受信任 CA 签发的服务器证书。
-->
<loadDefaultCAFile>true</loadDefaultCAFile>
<cacheSessions>true</cacheSessions>
<disableProtocols>sslv2,sslv3</disableProtocols>
<preferServerCiphers>true</preferServerCiphers>
<!-- Use for self-signed: <verificationMode>none</verificationMode> -->
<invalidCertificateHandler>
<!-- Use for self-signed: <name>AcceptCertificateHandler</name> -->
<name>RejectCertificateHandler</name>
</invalidCertificateHandler>
</client>
</openSSL>
<!-- http[s] 服务器上的默认根页面。例如，打开 http://localhost:8123 时从 https://tabix.io/ 加载 UI -->
<!--
<http_server_default_response><![CDATA[<html ng-app="SMI2"><head><base href="http://ui.tabix.io/"></head><body><div ui-view="" class="content-ui"></div><script src="http://loader.tabix.io/master.js"></script></body></html>]]></http_server_default_response>
-->
<!-- ============================================================= 优化参数相关配置 ================================================================ -->
<!--
允许运行所有查询的最大查询处理线程数（不包括用于从远程服务器检索数据的线程）。 这不是硬性限制。万一达到限制，查询仍将至少有一个线程运行。 如果有更多线程可用，查询可以在执行期间扩展到所需的线程数。
含义：设置并发线程的软限制的绝对数量。这个值限制了在执行查询时可以使用的线程数量。
默认值：默认情况下，这个值通常是根据系统资源自动确定的。当设置为 0 时，表示不启用该限制（使用系统默认配置）。
建议：通常保持为 0，除非你有明确的需求需要限制并发线程数量。在资源有限的环境中，可能需要设置一个具体的数字来防止系统资源耗尽。
-->
<concurrent_threads_soft_limit_num>0</concurrent_threads_soft_limit_num>
<!--
含义：设置并发线程数相对于 CPU 核心数的比例。例如，设置为 0.5 表示并发线程数不超过 CPU 核心数的一半。
默认值：当设置为 0 时，表示不启用这个限制（即系统根据需要使用全部可用核心）。
建议：一般建议设置为 0，让系统自动调整。如果你希望限制 CPU 使用率，可以根据你的系统负载情况设置一个合适的比例，比如 0.5 或 0.75。
-->
<concurrent_threads_soft_limit_ratio_to_cores>0</concurrent_threads_soft_limit_ratio_to_cores>
<!-- 最大数量的并发查询 -->
<max_concurrent_queries>1000</max_concurrent_queries>
<!--
用于设置 ClickHouse 服务器进程的最大内存使用量（常驻集大小，RSS）。这个值决定了服务器在处理查询时可以使用的最大内存量。
零值或未设置表示默认。默认值为可用物理 RAM 的“max_server_memory_usage_to_ram_ratio”。
如果该值大于可用物理RAM的“max_server_memory_usage_to_ram_ratio”，则会被削减。
根据查询执行时间检查约束。如果查询尝试分配内存并且当前内存使用量加上分配量更大，超过指定阈值，将抛出异常。将此约束设置为小值（例如几 GB）是不切实际的，因为内存分配器会将这些内存量保留在缓存中，并且服务器将拒绝查询服务。
含义：设置服务器进程可以使用的最大内存量。如果设置为 0 或未设置，则默认值为可用物理内存的一个比例（max_server_memory_usage_to_ram_ratio）。
作用：当查询执行时，如果当前内存使用量加上所需的内存分配超过此限制，查询会抛出异常并停止执行。
默认值：默认情况下，ClickHouse 会根据服务器的可用物理内存自动设置这个值（使用 max_server_memory_usage_to_ram_ratio 比例）。如果设置的值超过可用物理内存的比例限制，则会被自动缩减。
建议：一般情况下，建议将其设置为 0，以使用系统默认的内存管理策略。只有在需要严格控制服务器内存使用量时，才需设置具体值。设置过低可能导致服务器频繁抛出内存不足的异常，影响查询的执行。在设置时，建议考虑到服务器总内存和其他应用程序的内存需求。
-->
<max_server_memory_usage>0</max_server_memory_usage>
<!--
全局线程池中的最大线程数。
如果未指定(默认值)，这将默认为最多10000个线程。此设置在存在大量数据的情况下非常有用，并发运行但大部分空闲的分布式查询,在这种情况下，可能需要更多的线程。
建议：在分布式查询量大且并发量高的环境下，可能需要较多的线程来处理这些查询。在这种情况下，可以适当提高线程池的大小。默认值已经足够高，可以应对大部分情况下的高并发需求，避免手动调整的复杂性。
-->
<max_thread_pool_size>10000</max_thread_pool_size>
<!-- Configure other thread pools: -->
<!--
<background_buffer_flush_schedule_pool_size>16</background_buffer_flush_schedule_pool_size>
<background_pool_size>16</background_pool_size>
<background_merges_mutations_concurrency_ratio>2</background_merges_mutations_concurrency_ratio>
<background_merges_mutations_scheduling_policy>round_robin</background_merges_mutations_scheduling_policy>
<background_move_pool_size>8</background_move_pool_size>
<background_fetches_pool_size>8</background_fetches_pool_size>
<background_common_pool_size>8</background_common_pool_size>
<background_schedule_pool_size>128</background_schedule_pool_size>
<background_message_broker_schedule_pool_size>16</background_message_broker_schedule_pool_size>
<background_distributed_schedule_pool_size>16</background_distributed_schedule_pool_size>
-->
<!--
含义：定义服务器内存使用的最大比例，相对于可用物理内存的比率。在内存受限的环境中，您可能需要将其设置为大于1的值。
默认值：设置为 0.9 表示 ClickHouse 服务器最多可以使用 90% 的可用物理内存。
适用场景：如果服务器的内存资源紧张，可以通过调整此值来限制 ClickHouse 的内存使用，防止它消耗过多内存而影响其他进程的运行。
注意事项：在内存受限的环境中，可能需要将该值设置得比默认值更高，以确保查询不会因为内存不足而被拒绝执行。但过高的值也可能导致系统其他部分内存不足。
-->
<max_server_memory_usage_to_ram_ratio>0.9</max_server_memory_usage_to_ram_ratio>
<!-- Simple server-wide memory profiler. Collect a stack trace at every peak allocation step (in bytes).
Data will be stored in system.trace_log table with query_id = empty string.
含义：配置 ClickHouse 的简单内存分析器，定义在内存分配达到每个特定步长（以字节为单位）时收集堆栈跟踪的频率。
默认值：4194304 表示每当内存分配增加 4 MB 时，记录一次堆栈跟踪信息。
适用场景：适用于需要对内存使用情况进行详细分析和调优的场景。启用此功能可以帮助识别可能的内存泄漏或内存使用过多的查询。
注意事项：频繁记录堆栈跟踪可能会增加系统的开销，因此建议在分析或调试阶段启用此功能，【在生产环境中将此值设置为较大值或禁用（设为 0 表示禁用）】。
-->
<total_memory_profiler_step>4194304</total_memory_profiler_step>
<!-- Collect random allocations and deallocations and write them into system.trace_log with 'MemorySample' trace_type.
The probability is for every alloc/free regardless to the size of the allocation.
Note that sampling happens only when the amount of untracked memory exceeds the untracked memory limit,
which is 4 MiB by default but can be lowered if 'total_memory_profiler_step' is lowered.
You may want to set 'total_memory_profiler_step' to 1 for extra fine grained sampling.
含义：定义内存分配和释放的采样概率。该值表示每次内存分配或释放操作被采样记录的概率。
默认值：设置为 0 意味着禁用内存采样功能，即不会对内存操作进行采样记录。
适用场景：启用该功能有助于分析系统内存使用的模式，检测潜在的内存泄漏或优化内存分配策略。在系统负载较高或需要进行深入性能分析时，此功能尤其有用。
注意事项：采样功能会带来一定的性能开销，特别是在采样频率较高时。【因此在生产环境中，通常将采样概率设置为较低的值，甚至禁用采样，以免影响系统性能】。
禁用采样：将值设置为 0（如当前配置），完全禁用内存采样功能。这适用于无需进行内存分析的生产环境，以最大限度地减少系统开销。
启用采样：在调试或优化阶段，如果需要对内存使用情况进行详细分析，可以考虑启用采样。可以将值设置为一个非常小的概率值（如 0.01 或 0.001），以便在收集足够的采样数据的同时，尽量降低性能影响。
-->
<total_memory_tracker_sample_probability>0</total_memory_tracker_sample_probability>
<!--
含义：指定 ClickHouse 进程可打开的最大文件数。
默认值：默认为系统允许的最大文件数。
适用场景：当 ClickHouse 在 Mac OS X 或其他可能出现 getrlimit() 调用问题的环境中运行时，可能需要手动设置这个值以确保进程能够正常运行。
-->
<!-- <max_open_files>262144</max_open_files> -->
<!-- Size of cache of uncompressed blocks of data, used in tables of MergeTree family.
In bytes. Cache is single for server. Memory is allocated only on demand.
Cache is used when 'use_uncompressed_cache' user setting turned on (off by default).
Uncompressed cache is advantageous only for very short queries and in rare cases.
Note: uncompressed cache can be pointless for lz4, because memory bandwidth
is slower than multi-core decompression on some server configurations.
Enabling it can sometimes paradoxically make queries slower.
设置 ClickHouse 中未压缩数据块的缓存大小。此缓存主要在 MergeTree 系列的表中使用，旨在提高某些查询的性能。
含义：定义未压缩数据块缓存的大小，以字节为单位。该缓存用于存储从磁盘读取并解压缩后的数据块。
默认值：通常不设置默认值，但如果启用了缓存，则会根据需求动态分配内存。
使用场景：缓存适用于非常短的查询或特定情况下的查询性能优化。配置主要用于优化特定类型的查询，尤其是在内存资源充足且希望提升短查询性能的情况下。实际效果需要根据具体工作负载和系统配置进行测试和调整。
注意事项：由于在某些服务器配置中，未压缩缓存可能反而降低查询速度（特别是在使用 LZ4 压缩时，内存带宽比多核解压缩速度慢），因此默认情况下该功能是关闭的。
-->
<uncompressed_cache_size>8589934592</uncompressed_cache_size>
<!--
MergeTree家族表中使用的标记缓存的大致大小。以字节为单位。服务器的缓存是单一的。内存仅按需分配。你不应该降低这个值。
含义：定义标记缓存的大小，以字节为单位。标记缓存用于存储每个数据块的元数据（称为“标记”），这些元数据有助于快速定位并读取所需数据块，而无需遍历整个表。
默认值：通常没有明确的默认值，但不建议将该值设置得太低。
使用场景：适用于所有使用 MergeTree 系列表的 ClickHouse 实例，尤其是在需要高查询性能的场景下。通过合理设置缓存大小，可以显著减少查询时的磁盘访问次数，进而提高整体系统的响应速度。
缓存大小：缓存大小应根据服务器的内存资源和数据规模进行调整。5 GB (5368709120 字节) 是一个较为合理的配置，对于大部分生产环境来说，这个大小可以提供良好的查询性能。
注意事项：将此值设置得过低可能会导致频繁的磁盘访问，从而降低查询性能。因此，一般建议在内存资源允许的情况下尽可能配置较大的缓存。
-->
<mark_cache_size>5368709120</mark_cache_size>
<!--
如果启用“min_bytes_to_use_mmap_io”设置，MergeTree表中的数据可以使用mmap读取，以避免从内核复制到用户空间。
它只对大文件有意义，只有当数据驻留在页面缓存中时才有帮助。避免频繁的open/mmap/munmap/colose调用（由于随之而来的页面错误，这些调用非常昂贵）并重用来自多个线程和查询的映射，
映射文件的缓存得到维护。它的大小是映射区域的数量（通常等于映射文件的数量）。
可以监控映射文件中的数据量，在system.metrics、system.metric_log中，通过MMappedFiles、MMappedFile Bytes度量
在system.asynchronous_metrics、system.asynchrous_metrics_log中使用MMapCacheCells度量，
此外，在system.events、system.processes、system.query_log、system.query thread_log和system.query views_log中
CreatedReadBufferMMap、CreatedReadBuffer MMapFailed、MMappedFileCacheHits、MMappedCileCacheMisses事件。
请注意，映射文件中的数据量不会直接消耗内存，也不会被计入，在查询或服务器内存使用方面，因为这些内存可以像操作系统页面缓存一样被丢弃。
在MergeTree中删除旧部分时，缓存会自动删除（文件关闭），也可以通过SYSTEM DROP MMAP CACHE查询手动删除它。
设置 ClickHouse 中映射文件缓存的大小，即缓存的映射区域（通常等于映射文件的数量）。启用 mmap 选项后，MergeTree 表中的数据可以通过内存映射（mmap）进行读取，以避免从内核空间到用户空间的拷贝，从而提高 I/O 性能。
含义：定义映射文件缓存的大小，即缓存的映射区域数（通常等于映射文件的数量）。这有助于减少频繁的 open/mmap/munmap/close 系统调用，从而提高性能。
单位：该值表示缓存的映射区域数量，而不是内存的大小。
使用场景：适用于启用了 min_bytes_to_use_mmap_io 设置的大规模读操作，可以通过 mmap 读取数据以避免内核到用户空间的复制。此配置对于处理大型文件和系统 I/O 负载较大的情况下尤为有效。
缓存大小：缓存大小应根据查询工作负载的实际需求进行配置。1000 是一个适中的值，通常可以满足大多数场景的需求。
监控：可以通过 system.metrics、system.asynchronous_metrics 等系统表监控 mmap 缓存的使用情况，确保缓存设置合理，且系统没有因为缓存不足而频繁进行 mmap/munmap 操作。
-->
<mmap_cache_size>1000</mmap_cache_size>
<!--
已编译表达式的缓存大小。已编译表达式是 ClickHouse 在执行 SQL 查询时，将部分查询表达式编译为机器代码以提高执行效率。
含义：定义用于缓存已编译表达式的总内存大小，以bytes字节为单位。通过缓存已编译的表达式，ClickHouse 可以避免在重复查询中重新编译相同的表达式，从而节省 CPU 资源并加快查询执行速度。
默认值：如果未设置此值，ClickHouse 会使用默认的缓存大小。默认值未知
场景：在执行大量复杂查询，特别是包含重复表达式的大型查询时，此缓存可以显著提升性能。
缓存大小：134217728 字节（128 MB）是一个适中的配置，通常可以在中等负载的场景下提供良好的性能。如果你的 ClickHouse 实例处理大量复杂查询且内存资源充足，可以考虑增大该值。
性能监控：在调整此参数时，可以通过监控查询执行时间以及服务器的整体内存使用情况来评估缓存大小的效果。
-->
<compiled_expression_cache_size>134217728</compiled_expression_cache_size>
<!--
已编译表达式缓存的元素数量。与 <compiled_expression_cache_size> 相关，但它控制的是缓存中可以存储的编译表达式的数量，而不是内存大小。
含义：定义已编译表达式缓存中可以存储的表达式元素的数量。这个设置限制了缓存中可以保存的表达式数量，超过这个数量的表达式会被逐出缓存。
默认值：如果未设置此值，ClickHouse 使用默认的元素数量。默认值未知
场景：该配置适用于需要缓存大量表达式的场景。合适的设置可以提高查询性能，特别是在查询中重复使用了多个复杂表达式时。
元素数量：10000 是一个适中的设置，可以满足多数场景的需求。如果 ClickHouse 实例处理的查询复杂度高，且存在大量重复的编译表达式，考虑增加此值。
性能监控：可以通过监控缓存命中率以及查询执行时间来评估此配置的效果。如果发现大量缓存失效，可能需要调整这个值。
-->
<compiled_expression_cache_elements_size>10000</compiled_expression_cache_elements_size>
<!--
含义
true: 启用客户端信息验证。服务器会检查客户端的 IP 地址和端口号是否与实际连接信息匹配。这有助于确保连接的客户端是可信的，防止伪造的客户端信息。
false: 禁用客户端信息验证。服务器不会验证客户端的 IP 地址和端口信息。这可以提高性能，但可能降低安全性，因为服务器将信任所有提供的客户端信息。
-->
<validate_tcp_client_information>false</validate_tcp_client_information>
<!--
数据目录的路径，带有尾随斜线！
配置建议
确保目录存在: 确保配置的目录路径存在并且 ClickHouse 进程有写入权限。
适当分区: 如果可能，将数据目录放在性能较高的磁盘上，以提高数据库的 I/O 性能。
定期备份: 根据备份策略，定期备份数据目录，以防止数据丢失。
-->
<path>/data/clickhouse/data/</path>
<!-- Multi-disk configuration example: 多磁盘存储-->
<!--
<storage_configuration>
<disks>
<default>
<keep_free_space_bytes>0</keep_free_space_bytes>
</default>
<data>
<path>/data/</path>
<keep_free_space_bytes>0</keep_free_space_bytes>
</data>
<s3>
<type>s3</type>
<endpoint>http://path/to/endpoint</endpoint>
<access_key_id>your_access_key_id</access_key_id>
<secret_access_key>your_secret_access_key</secret_access_key>
</s3>
<blob_storage_disk>
<type>azure_blob_storage</type>
<storage_account_url>http://account.blob.core.windows.net</storage_account_url>
<container_name>container</container_name>
<account_name>account</account_name>
<account_key>pass123</account_key>
<metadata_path>/var/lib/clickhouse/disks/blob_storage_disk/</metadata_path>
<cache_enabled>true</cache_enabled>
<cache_path>/var/lib/clickhouse/disks/blob_storage_disk/cache/</cache_path>
<skip_access_check>false</skip_access_check>
</blob_storage_disk>
</disks>
<policies>
<all>
<volumes>
<main>
<disk>default</disk>
<disk>data</disk>
<disk>s3</disk>
<disk>blob_storage_disk</disk>
<max_data_part_size_bytes></max_data_part_size_bytes>
<max_data_part_size_ratio></max_data_part_size_ratio>
<perform_ttl_move_on_insert>true</perform_ttl_move_on_insert>
<prefer_not_to_merge>false</prefer_not_to_merge>
<load_balancing>round_robin</load_balancing>
</main>
</volumes>
<move_factor>0.2</move_factor>
</all>
</policies>
</storage_configuration>
-->
<!-- 用于处理硬查询的临时数据路径 -->
<tmp_path>/data/clickhouse/tmp/</tmp_path>
<!-- 禁用ACL的AuthType明文密码和无密码密码 -->
<!-- 控制是否允许使用明文密码进行身份验证。设置为 1 允许使用明文密码。如果您设置为 0，则将禁用明文密码的使用，通常这意味着您需要配置更安全的认证方法。 -->
<allow_plaintext_password>1</allow_plaintext_password>
<!-- 控制是否允许不使用密码的用户进行访问。设置为 1 允许不使用密码进行访问。如果设置为 0，则不允许不使用密码的访问，这增强了安全性。 -->
<allow_no_password>1</allow_no_password>
<!-- 控制是否允许隐式无密码认证，即在某些情况下自动允许没有密码的访问。设置为 1 允许这种隐式的无密码访问。如果设置为 0，则禁用此类访问，增加了认证的严格性。 -->
<allow_implicit_no_password>1</allow_implicit_no_password>
<!--
这个设置定义了在 CREATE USER 查询中如果用户没有指定密码类型时使用的默认密码类型。您可以选择以下几种密码类型：
plaintext_password: 明文密码，存储和传输时没有加密，安全性较低。
sha256_password: 使用 SHA-256 哈希算法加密的密码，提供更好的安全性。
double_sha1_password: 使用两次 SHA-1 哈希算法加密的密码，安全性比单次 SHA-1 更高，但不如 SHA-256。
bcrypt_password: 使用 bcrypt 哈希算法加密的密码，提供很高的安全性和防止暴力破解的保护。
安全性: sha256_password 是一个相对较安全的默认选项。如果您需要更高的安全性，可以考虑使用 bcrypt_password，尽管它可能会导致一些性能开销。
兼容性: 如果您有其他系统或服务与 ClickHouse 集成，确保它们支持您选择的密码类型。如果需要与旧系统兼容，选择 plaintext_password 或 double_sha1_password 可能更适合，但请注意，这些选项的安全性较低。
-->
<default_password_type>sha256_password</default_password_type>
<!--
这个设置定义了 bcrypt 密码哈希算法的工作因子（也称为“成本因子”）。工作因子决定了密码哈希计算的复杂度，值越高，计算越耗时，安全性也越高。工作因子的值通常在 4 到 31 之间。
较低的值（例如 10）会更快，但可能不如较高的值安全。
较高的值（例如 12 或更高）提供更好的安全性，但会增加计算时间和服务器负担。
安全性: bcrypt_workfactor 的默认值通常是 10 或 12。将工作因子设置为 12 是一个合理的平衡点，提供了较高的安全性，同时在性能上也不会造成过大的负担。根据您的系统负载和性能要求，您可以调整此值。
性能考虑: 高工作因子增加了计算哈希所需的时间，这可能会影响系统性能，尤其是在处理大量身份验证请求时。确保在选择工作因子时考虑系统的性能需求。
-->
<bcrypt_workfactor>12</bcrypt_workfactor>
<!--
Complexity requirements for user passwords.
这部分定义了密码复杂度的要求，确保用户的密码满足一定的安全标准。
<rule>: 每个规则定义了一个密码复杂度的要求。包括一个正则表达式模式和一个相关的提示消息。
<pattern>: 定义了密码必须匹配的正则表达式模式。每个模式指定了一个复杂度要求。
<message>: 定义了当密码不符合规则时显示的错误消息。它帮助用户理解密码要求并进行相应的修改。
-->
<!-- <password_complexity>
<rule>
<pattern>.{12}</pattern>
<message>密码必须至少包含 12 个字符</message>
</rule>
<rule>
<pattern>\p{N}</pattern>
<message>密码必须包含至少一个数字字符</message>
</rule>
<rule>
<pattern>\p{Ll}</pattern>
<message>密码必须包含至少一个小写字母</message>
</rule>
<rule>
<pattern>\p{Lu}</pattern>
<message>密码必须包含至少一个大写字母</message>
</rule>
<rule>
<pattern>[^\p{L}\p{N}]</pattern>
<message>密码必须包含至少一个特殊字符（非字母或数字）</message>
</rule>
</password_complexity> -->
<!--
用于指定 ClickHouse 的临时文件存储策略。临时文件通常在执行复杂查询或数据处理操作时生成，如果希望对临时文件的存储位置进行更细致的控制，可以考虑使用
如果配置了 <tmp_policy>，则 ClickHouse 会忽略 <tmp_path> 配置项，临时文件将按照指定的存储策略进行管理。
在 <tmp_policy> 中，你必须定义一个存储卷（volume），并且只能定义一个。如果未配置 <tmp_policy>，系统将使用默认的 <tmp_path> 目录来存储临时文件。
推荐场景：
大规模数据处理：当处理的临时文件量较大时，通过 <tmp_policy> 更好地管理这些文件的存储。
资源隔离：在具有多种存储资源的环境中，通过使用 <tmp_policy> 将临时文件与其他数据文件分离，避免相互干扰。
Notes:
- move_factor 指定在达到一定阈值时是否应移动数据文件，但在 <tmp_policy> 中被忽略。
- keep_free_space_bytes 指定要保留的空闲磁盘空间大小，但在 <tmp_policy> 中被忽略。
- max_data_part_size_bytes 指定单个数据部分的最大大小，但在 <tmp_policy> 中被忽略。
-->
<!-- Policy from the <storage_configuration> for the temporary files.
If not set <tmp_path> is used, otherwise <tmp_path> is ignored.
Notes:
- move_factor is ignored 指定在达到一定阈值时是否应移动数据文件
- keep_free_space_bytes is ignored
- max_data_part_size_bytes is ignored
- you must have exactly one volume in that policy
-->
<!-- <tmp_policy>tmp</tmp_policy> -->
<!--
用于存放用户提供的文件。这些文件可以通过 ClickHouse 的 file 表函数进行访问和查询。指定的目录通常位于 /var/lib/clickhouse/user_files/，这是默认的存放位置。
优点：
灵活的数据输入：允许用户通过文件直接加载数据到 ClickHouse 中，支持多种文件格式。
便捷的数据处理：用户可以将数据文件放置在指定目录中，然后使用 file 表函数在 SQL 查询中直接访问这些文件的数据，省去了中间的数据导入步骤。
推荐使用场景：
数据分析：需要对外部文件数据进行临时分析或处理时，可以将文件放置在该目录中，直接通过 SQL 查询进行分析。
测试与调试：在测试环境中，通过该目录快速加载测试数据文件，验证查询和处理逻辑。
-->
<user_files_path>/var/lib/clickhouse/user_files/</user_files_path>
<!--
这段配置文档介绍了 ClickHouse 中 LDAP 服务器的配置示例。它允许 ClickHouse 与 LDAP 服务器集成，用于用户认证和远程用户目录管理。以下是一些关键点：
LDAP 服务器配置：
<host>: 必填项，指定 LDAP 服务器的主机名或 IP 地址。
<port>: 指定 LDAP 服务器的端口号，默认情况下，当启用 TLS 时为 636，否则为 389。
<bind_dn>: 用于绑定到 LDAP 服务器的 DN 模板，可以用 {user_name} 占位符替换实际用户名。
用户 DN 检测：
<base_dn>: 用于 LDAP 搜索的基 DN 模板。
<search_filter>: 用于 LDAP 搜索的过滤器模板，可以用 {user_name} 占位符替换实际用户名。
TLS 相关设置：
<enable_tls>: 指定是否使用安全连接，推荐使用 yes。
<tls_minimum_protocol_version>: 指定 SSL/TLS 的最低协议版本。
<tls_require_cert>: 指定 SSL/TLS 对等证书验证行为。
示例配置：
提供了两个示例，一个是普通的 LDAP 配置，另一个是带有用户 DN 检测的 Active Directory 配置。
-->
<ldap_servers>
<!-- List LDAP servers with their connection parameters here to later 1) use them as authenticators for dedicated local users,
who have 'ldap' authentication mechanism specified instead of 'password', or to 2) use them as remote user directories.
Parameters:
host - LDAP server hostname or IP, this parameter is mandatory and cannot be empty.
port - LDAP server port, default is 636 if enable_tls is set to true, 389 otherwise.
bind_dn - template used to construct the DN to bind to.
The resulting DN will be constructed by replacing all '{user_name}' substrings of the template with the actual
user name during each authentication attempt.
user_dn_detection - section with LDAP search parameters for detecting the actual user DN of the bound user.
This is mainly used in search filters for further role mapping when the server is Active Directory. The
resulting user DN will be used when replacing '{user_dn}' substrings wherever they are allowed. By default,
user DN is set equal to bind DN, but once search is performed, it will be updated with to the actual detected
user DN value.
base_dn - template used to construct the base DN for the LDAP search.
The resulting DN will be constructed by replacing all '{user_name}' and '{bind_dn}' substrings
of the template with the actual user name and bind DN during the LDAP search.
scope - scope of the LDAP search.
Accepted values are: 'base', 'one_level', 'children', 'subtree' (the default).
search_filter - template used to construct the search filter for the LDAP search.
The resulting filter will be constructed by replacing all '{user_name}', '{bind_dn}', and '{base_dn}'
substrings of the template with the actual user name, bind DN, and base DN during the LDAP search.
Note, that the special characters must be escaped properly in XML.
verification_cooldown - a period of time, in seconds, after a successful bind attempt, during which a user will be assumed
to be successfully authenticated for all consecutive requests without contacting the LDAP server.
Specify 0 (the default) to disable caching and force contacting the LDAP server for each authentication request.
enable_tls - flag to trigger use of secure connection to the LDAP server.
Specify 'no' for plain text (ldap://) protocol (not recommended).
Specify 'yes' for LDAP over SSL/TLS (ldaps://) protocol (recommended, the default).
Specify 'starttls' for legacy StartTLS protocol (plain text (ldap://) protocol, upgraded to TLS).
tls_minimum_protocol_version - the minimum protocol version of SSL/TLS.
Accepted values are: 'ssl2', 'ssl3', 'tls1.0', 'tls1.1', 'tls1.2' (the default).
tls_require_cert - SSL/TLS peer certificate verification behavior.
Accepted values are: 'never', 'allow', 'try', 'demand' (the default).
tls_cert_file - path to certificate file.
tls_key_file - path to certificate key file.
tls_ca_cert_file - path to CA certificate file.
tls_ca_cert_dir - path to the directory containing CA certificates.
tls_cipher_suite - allowed cipher suite (in OpenSSL notation).
Example:
<my_ldap_server>
<host>localhost</host>
<port>636</port>
<bind_dn>uid={user_name},ou=users,dc=example,dc=com</bind_dn>
<verification_cooldown>300</verification_cooldown>
<enable_tls>yes</enable_tls>
<tls_minimum_protocol_version>tls1.2</tls_minimum_protocol_version>
<tls_require_cert>demand</tls_require_cert>
<tls_cert_file>/path/to/tls_cert_file</tls_cert_file>
<tls_key_file>/path/to/tls_key_file</tls_key_file>
<tls_ca_cert_file>/path/to/tls_ca_cert_file</tls_ca_cert_file>
<tls_ca_cert_dir>/path/to/tls_ca_cert_dir</tls_ca_cert_dir>
<tls_cipher_suite>ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:AES256-GCM-SHA384</tls_cipher_suite>
</my_ldap_server>
Example (typical Active Directory with configured user DN detection for further role mapping):
<my_ad_server>
<host>localhost</host>
<port>389</port>
<bind_dn>EXAMPLE\{user_name}</bind_dn>
<user_dn_detection>
<base_dn>CN=Users,DC=example,DC=com</base_dn>
<search_filter>(&(objectClass=user)(sAMAccountName={user_name}))</search_filter>
</user_dn_detection>
<enable_tls>no</enable_tls>
</my_ad_server>
-->
</ldap_servers>
<!-- Kerberos 认证支持，特别是用于 HTTP 请求的 GSS-SPNEGO 认证。Kerberos 是一种网络身份验证协议，允许用户在不重复输入密码的情况下访问多个服务。以下是一些关键点： -->
<!-- To enable Kerberos authentication support for HTTP requests (GSS-SPNEGO), for those users who are explicitly configured
to authenticate via Kerberos, define a single 'kerberos' section here.
Parameters:
principal - canonical service principal name, that will be acquired and used when accepting security contexts.
This parameter is optional, if omitted, the default principal will be used.
This parameter cannot be specified together with 'realm' parameter.
realm - a realm, that will be used to restrict authentication to only those requests whose initiator's realm matches it.
This parameter is optional, if omitted, no additional filtering by realm will be applied.
This parameter cannot be specified together with 'principal' parameter.
Example:
<kerberos />
Example:
<kerberos>
<principal>HTTP/clickhouse.example.com@EXAMPLE.COM</principal>
</kerberos>
Example:
<kerberos>
<realm>EXAMPLE.COM</realm>
</kerberos>
-->
<!-- 读取用户、角色、访问权限、设置配置文件、配额的来源。特别是如何使用本地 XML 文件和 LDAP 服务器作为用户目录 -->
<user_directories>
<users_xml>
<!-- 指定一个 XML 文件路径，用于存储预定义用户的配置信息 -->
<path>users.xml</path>
</users_xml>
<local_directory>
<!-- 指定一个本地目录路径，存储通过 SQL 命令创建的用户 -->
<path>/var/lib/clickhouse/access/</path>
</local_directory>
<!-- 可以将 LDAP 服务器添加为远程用户目录，如 S3、minio -->
<!-- To add an LDAP server as a remote user directory of users that are not defined locally, define a single 'ldap' section
with the following parameters:
server - one of LDAP server names defined in 'ldap_servers' config section above.
This parameter is mandatory and cannot be empty.
roles - section with a list of locally defined roles that will be assigned to each user retrieved from the LDAP server.
If no roles are specified here or assigned during role mapping (below), user will not be able to perform any
actions after authentication.
role_mapping - section with LDAP search parameters and mapping rules.
When a user authenticates, while still bound to LDAP, an LDAP search is performed using search_filter and the
name of the logged in user. For each entry found during that search, the value of the specified attribute is
extracted. For each attribute value that has the specified prefix, the prefix is removed, and the rest of the
value becomes the name of a local role defined in ClickHouse, which is expected to be created beforehand by
CREATE ROLE command.
There can be multiple 'role_mapping' sections defined inside the same 'ldap' section. All of them will be
applied.
base_dn - template used to construct the base DN for the LDAP search.
The resulting DN will be constructed by replacing all '{user_name}', '{bind_dn}', and '{user_dn}'
substrings of the template with the actual user name, bind DN, and user DN during each LDAP search.
scope - scope of the LDAP search.
Accepted values are: 'base', 'one_level', 'children', 'subtree' (the default).
search_filter - template used to construct the search filter for the LDAP search.
The resulting filter will be constructed by replacing all '{user_name}', '{bind_dn}', '{user_dn}', and
'{base_dn}' substrings of the template with the actual user name, bind DN, user DN, and base DN during
each LDAP search.
Note, that the special characters must be escaped properly in XML.
attribute - attribute name whose values will be returned by the LDAP search. 'cn', by default.
prefix - prefix, that will be expected to be in front of each string in the original list of strings returned by
the LDAP search. Prefix will be removed from the original strings and resulting strings will be treated
as local role names. Empty, by default.
Example:
<ldap>
<server>my_ldap_server</server>
<roles>
<my_local_role1 />
<my_local_role2 />
</roles>
<role_mapping>
<base_dn>ou=groups,dc=example,dc=com</base_dn>
<scope>subtree</scope>
<search_filter>(&(objectClass=groupOfNames)(member={bind_dn}))</search_filter>
<attribute>cn</attribute>
<prefix>clickhouse_</prefix>
</role_mapping>
</ldap>
Example (typical Active Directory with role mapping that relies on the detected user DN):
<ldap>
<server>my_ad_server</server>
<role_mapping>
<base_dn>CN=Users,DC=example,DC=com</base_dn>
<attribute>CN</attribute>
<scope>subtree</scope>
<search_filter>(&(objectClass=group)(member={user_dn}))</search_filter>
<prefix>clickhouse_</prefix>
</role_mapping>
</ldap>
-->
</user_directories>
<!-- 对 ClickHouse 的访问控制进行改进 -->
<access_control_improvements>
<!--
启用逻辑，使没有许可行策略的用户仍然可以使用SELECT查询读取行。控制那些没有定义行策略的用户是否可以通过 SELECT 查询读取行。
例如，如果有两个用户A、B，并且只为A定义了行策略，如果此设置为true，则用户B将看到所有行，如果此设置设置为false，则用户B将看不到任何行。默认情况下，为了与早期的访问配置兼容，此设置为false。
-->
<users_without_row_policies_can_read_rows>false</users_without_row_policies_can_read_rows>
<!--
控制 ON CLUSTER 查询是否需要 CLUSTER 授权。
默认值为 false，为了与早期版本的访问配置兼容，ON CLUSTER 查询忽略 CLUSTER 授权。如果设置为 true，则需要 CLUSTER 授权。
-->
<on_cluster_queries_require_cluster_grant>false</on_cluster_queries_require_cluster_grant>
<!--
默认值为 false，任何用户都可以执行 SELECT * FROM system.<table> 查询，不需要任何授权。如果设置为 true，则此类查询将需要特定的 GRANT SELECT ON system.<table> 授权，类似于非系统表的查询。
某些系统表（如 tables、columns、databases 等）仍然对所有用户开放，如果有 SHOW 权限（如 SHOW USERS），相应的系统表（如 system.users）也将可访问。
-->
<select_from_system_db_requires_grant>false</select_from_system_db_requires_grant>
<!--
控制是否需要授权才能从 information_schema 表中执行 SELECT * 查询。
默认值为 false，任何用户都可以执行 SELECT * FROM information_schema.<table> 查询，不需要任何授权。如果设置为 true，则此类查询将需要特定的 GRANT SELECT ON information_schema.<table> 授权。
-->
<select_from_information_schema_requires_grant>false</select_from_information_schema_requires_grant>
<!--
控制设置配置文件中的约束行为。
默认值为 false，为了向后兼容，特定设置的配置文件约束继承了先前配置文件中未设置的字段。如果设置为 true，则新约束会完全覆盖同一特定设置的先前约束（包括新约束未设置的字段），并启用 changeable_in_readonly 约束类型。
-->
<settings_constraints_replace_previous>false</settings_constraints_replace_previous>
<!-- 自上次访问角色以来存储在角色缓存中的秒数，控制角色在角色缓存中存储的时间（单位为秒） -->
<role_cache_expiration_time_seconds>600</role_cache_expiration_time_seconds>
</access_control_improvements>
<!-- Default profile of settings. -->
<default_profile>default</default_profile>
<!--
用于指定用户自定义设置的前缀，多个前缀可以用逗号分隔。
服务器将允许设置这些前缀开头的设置，并通过 getSetting 函数获取它们。些设置也会像其他设置一样记录在 query_log 中，但它们本身没有特别的作用，仅作为日志和配置记录。
例如，这里指定的前缀为 SQL_，这是为了与 MySQL 兼容，这些设置通常由 Tableau 等工具设置。这个配置对于使用外部工具（如 Tableau）与 ClickHouse 集成时非常有用，尤其是在需要兼容特定的 SQL 设置时。
-->
<custom_settings_prefixes>SQL_</custom_settings_prefixes>
<!-- System profile of settings. This settings are used by internal processes (Distributed DDL worker and so on). -->
<!-- <system_profile>default</system_profile> -->
<!-- 设置的缓冲区配置文件。缓冲区存储使用此设置将数据刷新到基础表。默认值：从system_profile指令中使用。-->
<!-- <buffer_profile>default</buffer_profile> -->
<!-- Default database. -->
<default_database>default</default_database>
<!--
这个设置用于指定服务器的时区
时区在以下场景中使用：
将 String 类型转换为 DateTime 类型时。
在打印 DateTime 时使用。
从文本中解析 DateTime 时使用。
在与日期和时间相关的函数中，如果没有传递特定的时区作为参数。
时区使用 IANA 时区数据库中的标识符，例如 UTC 或 Africa/Abidjan。
如果没有指定时区，ClickHouse 会使用服务器启动时的系统时区。
服务器可能会显示时区别名，而不是指定的名称。例如：Zulu 是 UTC 的别名。
如果希望确保 ClickHouse 处理日期和时间的一致性，特别是在跨时区的环境中，指定合适的时区是很重要的。
-->
<!-- <timezone>UTC</timezone> -->
<!--
指定 ClickHouse 服务器启动时应用的 umask 值。具体内容如下：
umask:
umask 是一个用于设置默认文件权限的掩码（mask），它决定了新创建文件和目录的默认权限。
数值以八进制形式解析。
默认的 umask 值是 027，这意味着：
其他用户不能读取日志、数据文件等。
所有者和组用户具有读取权限。
你可以通过设置 umask 值来调整这些权限。例如，022 会使新创建的文件和目录对所有用户可读，但对组和其他用户的写权限被限制。
示例
默认 umask（027）:
文件: （所有者读写，组读，其他无权限）
目录: （所有者读写执行，组读执行，其他无权限）
设置 umask 为 022:
文件: （所有者读写，组和其他用户读取）
目录: （所有者读写执行，组和其他用户读取执行）
根据你的安全需求，你可以调整这个值来适应不同的访问控制策略。
-->
<!-- <umask>022</umask> -->
<!--
控制是否在启动后对 ClickHouse 可执行文件进行内存锁定。这样做可以降低初次查询的延迟，并防止在高 IO 负载下 ClickHouse 可执行文件被换出到磁盘。
true : 启用内存锁定
false : 禁用内存锁定
启用 mlock_executable 是推荐的做法，特别是在内存压力较大的环境中，它可以显著提高系统的性能。启用此选项会增加启动时间。
-->
<mlock_executable>true</mlock_executable>
<!--
是否使用大页内存来重新分配机器代码（"text"）。这是一个高度实验性的功能。
true : 启用大页内存重新分配。
false : 禁用大页内存重新分配。
启用 remap_executable 可以在某些特定的高性能环境中提高性能，但由于其实验性质，可能会带来不稳定的效果。通常情况下，建议保持此选项为 false 以确保系统的稳定性。
-->
<remap_executable>false</remap_executable>
<!-- 通过配置 jdbc_bridge 来启用 JDBC 表引擎和函数 -->
<![CDATA[
Uncomment below in order to use JDBC table engine and function.
To install and run JDBC bridge in background:
* [Debian/Ubuntu]
export MVN_URL=https://repo1.maven.org/maven2/com/clickhouse/clickhouse-jdbc-bridge/
export PKG_VER=$(curl -sL $MVN_URL/maven-metadata.xml | grep '<release>' | sed -e 's|.*>\(.*\)<.*|\1|')
wget https://github.com/ClickHouse/clickhouse-jdbc-bridge/releases/download/v$PKG_VER/clickhouse-jdbc-bridge_$PKG_VER-1_all.deb
apt install --no-install-recommends -f ./clickhouse-jdbc-bridge_$PKG_VER-1_all.deb
clickhouse-jdbc-bridge &
* [CentOS/RHEL]
export MVN_URL=https://repo1.maven.org/maven2/com/clickhouse/clickhouse-jdbc-bridge/
export PKG_VER=$(curl -sL $MVN_URL/maven-metadata.xml | grep '<release>' | sed -e 's|.*>\(.*\)<.*|\1|')
wget https://github.com/ClickHouse/clickhouse-jdbc-bridge/releases/download/v$PKG_VER/clickhouse-jdbc-bridge-$PKG_VER-1.noarch.rpm
yum localinstall -y clickhouse-jdbc-bridge-$PKG_VER-1.noarch.rpm
clickhouse-jdbc-bridge &
Please refer to https://github.com/ClickHouse/clickhouse-jdbc-bridge#usage for more information.
]]>
<!--
<jdbc_bridge>
<host>127.0.0.1</host>
<port>9019</port>
</jdbc_bridge>
-->
<!-- ================================================= 分割线内的配置，已在 config.d/metrika.xml 替换，此处可忽略 =============================================================== -->
<!-- 可用于分布式表的集群配置。https://clickhouse.com/docs/en/operations/table_engines/distributed/ -->
<remote_servers>
<!-- Test only shard config for testing distributed storage -->
<default>
<!-- Inter-server per-cluster secret for Distributed queries
default: no secret (no authentication will be performed)
If set, then Distributed queries will be validated on shards, so at least:
- such cluster should exist on the shard,
- such cluster should have the same secret.
And also (and which is more important), the initial_user will
be used as current user for the query.
Right now the protocol is pretty simple and it only takes into account:
- cluster name
- query
Also it will be nice if the following will be implemented:
- source hostname (see interserver_http_host), but then it will depends from DNS,
it can use IP address instead, but then the you need to get correct on the initiator node.
- target hostname / ip address (same notes as for source hostname)
- time-based security tokens
-->
<!-- <secret></secret> -->
<shard>
<!-- 可选的，用于配置是否仅向一个副本写入数据。如果设置为 true，数据将只写入一个副本，默认值是 false（写入所有副本）。 -->
<!-- <internal_replication>false</internal_replication> -->
<!-- 可选的，用于配置分片的权重。默认值为 1。权重决定了在负载均衡时该分片的优先级。 -->
<!-- <weight>1</weight> -->
<replica>
<host>localhost</host>
<port>9000</port>
<!-- Optional. Priority of the replica for load_balancing. Default: 1 (less value has more priority). -->
<!-- <priority>1</priority> -->
<!-- Use SSL? Default: no -->
<!-- <secure>0</secure> -->
</replica>
</shard>
</default>
</remote_servers>
<!-- The list of hosts allowed to use in URL-related storage engines and table functions.
If this section is not present in configuration, all hosts are allowed.
-->
<!--<remote_url_allow_hosts>-->
<!-- Host should be specified exactly as in URL. The name is checked before DNS resolution.
Example: "clickhouse.com", "clickhouse.com." and "www.clickhouse.com" are different hosts.
If port is explicitly specified in URL, the host:port is checked as a whole.
If host specified here without port, any port with this host allowed.
"clickhouse.com" -> "clickhouse.com:443", "clickhouse.com:80" etc. is allowed, but "clickhouse.com:80" -> only "clickhouse.com:80" is allowed.
If the host is specified as IP address, it is checked as specified in URL. Example: "[2a02:6b8:a::a]".
If there are redirects and support for redirects is enabled, every redirect (the Location field) is checked.
Host should be specified using the host xml tag:
<host>clickhouse.com</host>
-->
<!-- Regular expression can be specified. RE2 engine is used for regexps.
Regexps are not aligned: don't forget to add ^ and $. Also don't forget to escape dot (.) metacharacter
(forgetting to do so is a common source of error).
-->
<!--</remote_url_allow_hosts>-->
<!-- The list of HTTP headers forbidden to use in HTTP-related storage engines and table functions.
If this section is not present in configuration, all headers are allowed.
-->
<!-- <http_forbid_headers>
<header>exact_header</header>
<header_regexp>(?i)(case_insensitive_header)</header_regexp>
</http_forbid_headers> -->
<!-- If element has 'incl' attribute, then for it's value will be used corresponding substitution from another file.
By default, path to file with substitutions is /etc/metrika.xml. It could be changed in config in 'include_from' element.
Values for substitutions are specified in /clickhouse/name_of_substitution elements in that file.
-->
<!-- ZooKeeper is used to store metadata about replicas, when using Replicated tables.
Optional. If you don't use replicated tables, you could omit that.
See https://clickhouse.com/docs/en/engines/table-engines/mergetree-family/replication/
-->
<!--
<zookeeper>
<node>
<host>example1</host>
<port>2181</port>
</node>
<node>
<host>example2</host>
<port>2181</port>
</node>
<node>
<host>example3</host>
<port>2181</port>
</node>
</zookeeper>
-->
<!-- Substitutions for parameters of replicated tables.
Optional. If you don't use replicated tables, you could omit that.
See https://clickhouse.com/docs/en/engines/table-engines/mergetree-family/replication/#creating-replicated-tables
-->
<!--
<macros>
<shard>01</shard>
<replica>example01-01-1</replica>
</macros>
-->
<!-- ======================================================================================================================================= -->
<!-- 指定了嵌入式字典的重新加载间隔时间，以秒为单位。它控制 ClickHouse 如何频繁地重新加载内置字典，以便在字典发生变化时能够更新数据。默认值为 3600 秒，即每小时重新加载一次。这个配置有助于在使用动态字典的场景中保持数据的最新性。-->
<builtin_dictionaries_reload_interval>3600</builtin_dictionaries_reload_interval>
<!-- session会话的最大超时时间，以秒为单位。当用户的session会话达到这个超时时间后，会话将被自动结束。默认值为 3600 秒，即一个小时。 -->
<max_session_timeout>3600</max_session_timeout>
<!-- session会话的默认超时时间，以秒为单位。默认值为 60 秒 -->
<default_session_timeout>60</default_session_timeout>
<!-- =============================================================== 集成开源监控 =================================================================== -->
<!-- 将 ClickHouse 的监控数据发送到 Graphite，这是一个开源的监控和图形展示工具。Graphite 能够实时收集、存储和展示时间序列数据 -->
<!--
interval
用途: 决定数据发送到 Graphite 的频率，以秒为单位。例如，60 表示每分钟发送一次数据。
示例: 60 表示每 60 秒发送一次数据，1 表示每秒发送一次数据。
root_path
用途: 设置在 Graphite 中用于存储数据的根路径前缀。通过根路径组织数据，便于后续的查询和图形展示。
示例: one_min 或 one_sec，根据数据发送的频率来设置不同的路径。
hostname_in_path
用途: 指定是否在 Graphite 路径中附加主机名。这对于在多主机环境中区分不同主机的数据非常有用。
示例: true 表示在路径中包含主机名，false 表示不包含。
metrics
用途: 指定是否将 system.metrics 表中的数据发送到 Graphite。system.metrics 表包含 ClickHouse 的各种性能指标。
示例: true 表示发送 system.metrics 表的数据，false 表示不发送。
events
用途: 指定是否将 system.events 表中的数据发送到 Graphite。system.events 表记录了 ClickHouse 中发生的各种事件。
示例: true 表示发送 system.events 表的数据，false 表示不发送。
events_cumulative
用途: 指定是否发送累计事件数据。这种数据记录了事件的总数，适用于需要查看事件累计情况的场景。
示例: true 表示发送累计事件数据，false 表示不发送。
asynchronous_metrics
用途: 指定是否将 system.asynchronous_metrics 表中的数据发送到 Graphite。system.asynchronous_metrics 表包含异步操作的性能指标。
示例: true 表示发送 system.asynchronous_metrics 表的数据，false 表示不发送。
timeout
用途: 设置连接到 Graphite 服务器的超时时间，以秒为单位。用于处理网络延迟或连接问题。
示例: 0.1 表示超时时间为 100 毫秒。
port
用途: 指定 Graphite 服务器监听的端口号。
示例: 42000 是 Graphite 接收数据的端口号。
host
用途: 指定 Graphite 服务器的主机名或 IP 地址。
示例: localhost 表示 Graphite 服务器运行在本地主机上。
-->
<!--
<graphite>
<host>localhost</host>
<port>42000</port>
<timeout>0.1</timeout>
<interval>60</interval>
<root_path>one_min</root_path>
<hostname_in_path>true</hostname_in_path>
<metrics>true</metrics>
<events>true</events>
<events_cumulative>false</events_cumulative>
<asynchronous_metrics>true</asynchronous_metrics>
</graphite>
<graphite>
<host>localhost</host>
<port>42000</port>
<timeout>0.1</timeout>
<interval>1</interval>
<root_path>one_sec</root_path>
<metrics>true</metrics>
<events>true</events>
<events_cumulative>false</events_cumulative>
<asynchronous_metrics>false</asynchronous_metrics>
</graphite>
-->
<!-- 发送到 prometheus 监控 -->
<!--
endpoint
用途: 设置 Prometheus 服务器上用于接收指标数据的路径。路径相对于服务器的根路径，必须以斜杠 / 开始。
示例: /metrics 表示 Prometheus 将从 /metrics 路径获取指标数据。
port
用途: 指定用于 Prometheus 指标的 HTTP 端口。如果未定义或设置为 0，则使用 http_port 配置的端口。
示例: 9363 表示 Prometheus 将通过端口 9363 访问 ClickHouse 指标。
metrics
用途: 指定是否将 system.metrics 表中的数据发送到 Prometheus。system.metrics 表包含 ClickHouse 的各种性能指标。
示例: true 表示发送 system.metrics 表的数据，false 表示不发送。
events
用途: 指定是否将 system.events 表中的数据发送到 Prometheus。system.events 表记录 ClickHouse 中发生的各种事件。
示例: true 表示发送 system.events 表的数据，false 表示不发送。
asynchronous_metrics
用途: 指定是否将 system.asynchronous_metrics 表中的数据发送到 Prometheus。system.asynchronous_metrics 表包含异步操作的性能指标。
示例: true 表示发送 system.asynchronous_metrics 表的数据，false 表示不发送。
status_info
用途: 指定是否发送其他 ClickHouse 组件的状态信息（如字典状态）到 Prometheus。
示例: true 表示发送状态信息，false 表示不发送。
-->
<!--
<prometheus>
<endpoint>/metrics</endpoint>
<port>9363</port>
<metrics>true</metrics>
<events>true</events>
<asynchronous_metrics>true</asynchronous_metrics>
<status_info>true</status_info>
</prometheus>
-->
<!-- ============================================================================================================================================================== -->
<!-- =============================================================== 设置 ClickHouse 的各种 log 配置================================================================= -->
<!-- ============================================================================================================================================================== -->
<!--
database
用途: 指定存储查询日志的数据库。如果数据库不存在，ClickHouse 会自动创建它。
示例: system 表示查询日志将存储在 system 数据库中。
table
用途: 指定存储查询日志的表名。如果表不存在，ClickHouse 会自动创建它。
示例: query_log 表示查询日志将存储在名为 query_log 的表中。
partition_by
用途: 定义日志表的分区键。数据将按指定的分区键进行分区，有助于优化查询性能和数据管理。
示例: toYYYYMM(event_date) 表示按日志事件日期的年月分区。例如，日志会按每个月分区。
ttl
用途: 设置表的数据过期时间。过期的数据会被自动删除或迁移到指定的磁盘。
示例: event_date + INTERVAL 30 DAY DELETE 表示事件日期超过 30 天的数据会被自动删除。
order_by
用途: 定义日志表的排序键。数据会按指定的排序键进行排序，以优化查询性能。
示例: event_date, event_time, initial_query_id 表示按事件日期、事件时间和初始查询 ID 排序。
engine
用途: 完整的表引擎表达式，包括引擎类型和参数。可以用来替代 partition_by 和 order_by 配置。
示例: ENGINE = MergeTree PARTITION BY toYYYYMM(event_date) ORDER BY (event_date, event_time) SETTINGS index_granularity = 1024 表示使用 MergeTree 引擎，并指定分区和排序键，以及其他设置。
flush_interval_milliseconds
用途: 设置日志数据的刷新间隔时间，单位为毫秒。日志数据将在此间隔时间后刷新到磁盘。
示例: 7500 表示每 7500 毫秒（7.5 秒）刷新一次日志数据。
max_size_rows
用途: 设置日志的最大行数。当日志行数达到此值时，数据将被刷新到磁盘。
示例: 1048576 表示最大行数为 1048576 行。
reserved_size_rows
用途: 设置日志的预分配行数。在预分配行数内的数据不会立即刷新到磁盘。
示例: 8192 表示预分配 8192 行数据。
buffer_size_rows_flush_threshold
用途: 设置日志缓冲区的行数阈值。当缓冲区中的日志行数达到此值时，数据将在后台刷新到磁盘。
示例: 524288 表示缓冲区行数阈值为 524288 行。
flush_on_crash
用途: 指定在系统崩溃时是否将日志刷新到磁盘。若设置为 true，则在崩溃时会尽量保存日志数据。
示例: false 表示在崩溃时不会强制刷新日志数据。
storage_policy
用途: （可选）指定系统表使用的存储策略。例如，可以指定将数据存储在本地 SSD 上。
示例: local_ssd 表示使用本地 SSD 存储。
-->
<!-- Query log. Used only for queries with setting log_queries = 1. -->
<query_log>
<!-- What table to insert data. If table is not exist, it will be created.
When query log structure is changed after system update,
then old table will be renamed and new table will be created automatically.
-->
<database>system</database>
<table>query_log</table>
<!--
PARTITION BY expr: https://clickhouse.com/docs/en/table_engines/mergetree-family/custom_partitioning_key/
Example:
event_date
toMonday(event_date)
toYYYYMM(event_date)
toStartOfHour(event_time)
-->
<partition_by>toYYYYMM(event_date)</partition_by>
<!--
Table TTL specification: https://clickhouse.com/docs/en/engines/table-engines/mergetree-family/mergetree/#mergetree-table-ttl
Example:
event_date + INTERVAL 1 WEEK
event_date + INTERVAL 7 DAY DELETE
event_date + INTERVAL 2 WEEK TO DISK 'bbb'
<ttl>event_date + INTERVAL 30 DAY DELETE</ttl>
-->
<!--
ORDER BY expr: https://clickhouse.com/docs/en/engines/table-engines/mergetree-family/mergetree#order_by
Example:
event_date, event_time
event_date, type, query_id
event_date, event_time, initial_query_id
<order_by>event_date, event_time, initial_query_id</order_by>
-->
<!-- Instead of partition_by, you can provide full engine expression (starting with ENGINE = ) with parameters,
Example: <engine>ENGINE = MergeTree PARTITION BY toYYYYMM(event_date) ORDER BY (event_date, event_time) SETTINGS index_granularity = 1024</engine>
-->
<!-- Interval of flushing data. -->
<flush_interval_milliseconds>7500</flush_interval_milliseconds>
<!-- Maximal size in lines for the logs. When non-flushed logs amount reaches max_size, logs dumped to the disk. -->
<max_size_rows>1048576</max_size_rows>
<!-- Pre-allocated size in lines for the logs. -->
<reserved_size_rows>8192</reserved_size_rows>
<!-- Lines amount threshold, reaching it launches flushing logs to the disk in background. -->
<buffer_size_rows_flush_threshold>524288</buffer_size_rows_flush_threshold>
<!-- Indication whether logs should be dumped to the disk in case of a crash -->
<flush_on_crash>false</flush_on_crash>
<!-- example of using a different storage policy for a system table -->
<!-- storage_policy>local_ssd</storage_policy -->
</query_log>
<!-- Trace log.存储查询分析器收集的堆栈跟踪。
详见 query_profiler_real_time_period_ns 、 query_profiler_cpu_time_period_ns 设置. -->
<trace_log>
<!--
用途: 指定存储追踪日志的数据库。如果数据库不存在，ClickHouse 会自动创建它。
示例: system 表示追踪日志将存储在 system 数据库中。
-->
<database>system</database>
<!--
用途: 指定存储追踪日志的表名。如果表不存在，ClickHouse 会自动创建它。
示例: trace_log 表示追踪日志将存储在名为 trace_log 的表中。
-->
<table>trace_log</table>
<!--
用途: 定义日志表的分区键。数据将按指定的分区键进行分区，有助于优化查询性能和数据管理。
示例: toYYYYMM(event_date) 表示按日志事件日期的年月分区。例如，日志会按每个月分区。
-->
<partition_by>toYYYYMM(event_date)</partition_by>
<!-- 设置日志数据的刷新间隔时间，单位为毫秒。日志数据将在此间隔时间后刷新到磁盘。 -->
<flush_interval_milliseconds>7500</flush_interval_milliseconds>
<!-- 设置日志的最大行数。当日志行数达到此值时，数据将被刷新到磁盘。 -->
<max_size_rows>1048576</max_size_rows>
<!-- 设置日志的预分配行数。在预分配行数内的数据不会立即刷新到磁盘。 -->
<reserved_size_rows>8192</reserved_size_rows>
<!-- 设置日志缓冲区的行数阈值。当缓冲区中的日志行数达到此值时，数据将在后台刷新到磁盘。 -->
<buffer_size_rows_flush_threshold>524288</buffer_size_rows_flush_threshold>
<!-- 指定在系统崩溃时是否将日志刷新到磁盘。若设置为 true，则在崩溃时会尽量保存日志数据。false 表示在崩溃时不会强制刷新日志数据。 -->
<flush_on_crash>false</flush_on_crash>
</trace_log>
<!-- 查询执行的所有线程的信息. Has information about all threads participated in query execution.
Used only for queries with setting log_query_threads = 1. -->
<query_thread_log>
<database>system</database>
<table>query_thread_log</table>
<partition_by>toYYYYMM(event_date)</partition_by>
<flush_interval_milliseconds>7500</flush_interval_milliseconds>
<max_size_rows>1048576</max_size_rows>
<reserved_size_rows>8192</reserved_size_rows>
<buffer_size_rows_flush_threshold>524288</buffer_size_rows_flush_threshold>
<flush_on_crash>false</flush_on_crash>
</query_thread_log>
<!-- 查询视图 Query views log. Has information about all dependent views associated with a query.
Used only for queries with setting log_query_views = 1. -->
<query_views_log>
<database>system</database>
<table>query_views_log</table>
<partition_by>toYYYYMM(event_date)</partition_by>
<flush_interval_milliseconds>7500</flush_interval_milliseconds>
</query_views_log>
<!-- Uncomment if use part log.
Part log contains information about all actions with parts in MergeTree tables (creation, deletion, merges, downloads).
记录所有关于 MergeTree 表数据分区的操作（如创建、删除、合并）可以帮助监控和管理表的数据状态。
适用:
MergeTree 及其变体（如 SummingMergeTree、AggregatingMergeTree、ReplacingMergeTree 等）。
不适用:
不适用于简单的表引擎，如 Log、TinyLog、Memory，这些表引擎通常不涉及复杂的分区和合并操作。
通过配置 part_log，你可以确保 MergeTree 表的操作被详细记录，从而获得更好的管理和监控能力。
-->
<part_log>
<database>system</database>
<table>part_log</table>
<partition_by>toYYYYMM(event_date)</partition_by>
<flush_interval_milliseconds>7500</flush_interval_milliseconds>
<max_size_rows>1048576</max_size_rows>
<reserved_size_rows>8192</reserved_size_rows>
<buffer_size_rows_flush_threshold>524288</buffer_size_rows_flush_threshold>
<flush_on_crash>false</flush_on_crash>
</part_log>
<!-- Uncomment to write text log into table.
Text log contains all information from usual server log but stores it in structured and efficient way.
The level of the messages that goes to the table can be limited (<level>), if not specified all messages will go to the table.
<text_log>
<database>system</database>
<table>text_log</table>
<flush_interval_milliseconds>7500</flush_interval_milliseconds>
<max_size_rows>1048576</max_size_rows>
<reserved_size_rows>8192</reserved_size_rows>
<buffer_size_rows_flush_threshold>524288</buffer_size_rows_flush_threshold>
<flush_on_crash>false</flush_on_crash>
<level></level>
</text_log>
-->
<!-- Metric log contains rows with current values of ProfileEvents, CurrentMetrics collected with "collect_interval_milliseconds" interval.
用于存储 ClickHouse 的指标数据（Metrics）。这些指标数据包括 ProfileEvents 和 CurrentMetrics，它们提供有关 ClickHouse 系统性能和状态的信息。将这些指标数据存储在表中有助于对系统进行深入分析和监控。
metric_log 用于存储和监控 ClickHouse 的各种系统指标，如查询性能、资源使用情况和系统负载等。这有助于实时跟踪和分析系统性能。
问题诊断: 存储的指标数据可以用于诊断系统中的性能瓶颈或异常情况。例如，长时间的高负载或资源消耗异常可以通过分析这些数据来发现。
确保对日志表进行适当的维护和管理，例如定期清理旧日志，以防止日志表无限制增长。
-->
<metric_log>
<!-- system 库 -->
<database>system</database>
<!-- metric_log 表 -->
<table>metric_log</table>
<!-- 指定将内存中的指标数据刷新到磁盘的时间间隔（以毫秒为单位）。默认值是 7500 毫秒。这有助于控制指标的写入频率和系统性能。 -->
<flush_interval_milliseconds>7500</flush_interval_milliseconds>
<!-- 指定指标表中可以容纳的最大行数。当指标行数达到这个值时，系统将自动将其刷新到磁盘。默认值是 1048576 行。 -->
<max_size_rows>1048576</max_size_rows>
<!-- 指定为指标预留的行数。这个配置确保在高负载情况下日志表不会立即填满。默认值是 8192 行。 -->
<reserved_size_rows>8192</reserved_size_rows>
<!-- 指定在后台自动刷新指标之前，内存中保留的指标行数阈值。默认值是 524288 行。 -->
<buffer_size_rows_flush_threshold>524288</buffer_size_rows_flush_threshold>
<!-- 指定收集指标数据的时间间隔（以毫秒为单位）。默认值是 1000 毫秒，即每秒收集一次指标数据。这是一个关键参数，决定了系统监控的粒度和频率。 -->
<collect_interval_milliseconds>1000</collect_interval_milliseconds>
<!-- 指定是否在系统崩溃时将指标数据刷新到磁盘。如果设置为 true，则在系统崩溃时会尽可能将指标数据保存到磁盘，以防数据丢失。默认值是 false。 -->
<flush_on_crash>false</flush_on_crash>
</metric_log>
<!--
Asynchronous metric log contains values of metrics from system.asynchronous_metrics.
asynchronous_metric_log 配置项用于存储 ClickHouse 系统中的异步指标数据。这些异步指标是从 system.asynchronous_metrics 表中收集的，通常反映的是一些定期计算或更新的指标，这些指标不一定在每次查询时实时计算。
异步指标通常包括系统的资源使用情况、I/O 操作统计、缓存命中率等。这些指标数据可以帮助运维人员监控系统状态，并及时发现和解决潜在问题。
存储异步指标数据有助于进行长期的趋势分析和历史数据回溯
-->
<asynchronous_metric_log>
<!-- system 库 -->
<database>system</database>
<!-- asynchronous_metric_log 表 -->
<table>asynchronous_metric_log</table>
<!-- 指定将内存中的异步指标数据刷新到磁盘的时间间隔（以毫秒为单位）。默认设置为 7000 毫秒（即每 7 秒刷新一次）。这个值决定了数据写入磁盘的频率。 -->
<flush_interval_milliseconds>7000</flush_interval_milliseconds>
<!-- 指定异步指标表中可以容纳的最大行数。当行数达到这个限制时，系统会将数据刷新到磁盘。默认值是 1048576 行。 -->
<max_size_rows>1048576</max_size_rows>
<!-- 指定为异步指标预留的行数。这个值用于确保日志表在高负载下不会立即填满，默认值为 8192 行。 -->
<reserved_size_rows>8192</reserved_size_rows>
<!-- 指定在后台自动刷新异步指标数据之前，内存中保留的行数阈值。默认值是 524288 行。 -->
<buffer_size_rows_flush_threshold>524288</buffer_size_rows_flush_threshold>
<!-- 指定在系统崩溃时是否将异步指标数据刷新到磁盘。如果设置为 true，则在系统崩溃时会尝试将数据保存到磁盘，以避免数据丢失。默认值为 false。 -->
<flush_on_crash>false</flush_on_crash>
</asynchronous_metric_log>
<!--
OpenTelemetry log contains OpenTelemetry trace spans.
存储来自 OpenTelemetry 的追踪跨度（trace spans）数据。OpenTelemetry 是一个用于分布式追踪和指标收集的开源工具，通常用于监控和调试复杂的分布式系统。
分布式追踪: 在分布式系统中，跟踪请求的流向和时间是调试性能问题的关键。通过记录每个请求的追踪跨度，可以全面了解请求在系统中的生命周期。
监控和调试: 这些追踪数据可以帮助开发人员监控系统的行为，识别瓶颈，并快速定位问题所在。
性能影响: 存储和处理大量追踪数据可能对系统的 I/O 性能产生影响。建议根据实际的追踪数据量调整刷新间隔和其他参数。
整合分析: 可以将这些追踪数据与其他监控数据整合，提供更全面的系统运行状况视图。
-->
<opentelemetry_span_log>
<!--
The default table creation code is insufficient, this <engine> spec
is a workaround. There is no 'event_time' for this log, but two times,
start and finish. It is sorted by finish time, to avoid inserting
data too far away in the past (probably we can sometimes insert a span
that is seconds earlier than the last span in the table, due to a race
between several spans inserted in parallel). This gives the spans a
global order that we can use to e.g. retry insertion into some external
system.
-->
<!-- 指定表的存储引擎和相关的配置参数。在这里，使用 MergeTree 作为存储引擎，并且基于 finish_date 进行分区（partition by toYYYYMM(finish_date)）。表的数据会根据 finish_date, finish_time_us, 和 trace_id 进行排序，这样可以保证追踪数据的全局顺序，以便在必要时重新插入到外部系统。 -->
<engine>
engine MergeTree
partition by toYYYYMM(finish_date)
order by (finish_date, finish_time_us, trace_id)
</engine>
<database>system</database>
<table>opentelemetry_span_log</table>
<!-- 指定将内存中的追踪跨度数据刷新到磁盘的时间间隔（以毫秒为单位）。默认设置为 7500 毫秒（即每 7.5 秒刷新一次）。 -->
<flush_interval_milliseconds>7500</flush_interval_milliseconds>
<!-- 指定追踪跨度表中可以容纳的最大行数。当行数达到这个限制时，系统会将数据刷新到磁盘。默认值是 1048576 行。 -->
<max_size_rows>1048576</max_size_rows>
<!-- 指定为追踪跨度数据预留的行数。这个值用于确保日志表在高负载下不会立即填满，默认值为 8192 行。 -->
<reserved_size_rows>8192</reserved_size_rows>
<!-- 指定在后台自动刷新追踪跨度数据之前，内存中保留的行数阈值。默认值是 524288 行。 -->
<buffer_size_rows_flush_threshold>524288</buffer_size_rows_flush_threshold>
<!-- 指定在系统崩溃时是否将追踪跨度数据刷新到磁盘。如果设置为 true，则在系统崩溃时会尝试将数据保存到磁盘，以避免数据丢失。默认值为 false。 -->
<flush_on_crash>false</flush_on_crash>
</opentelemetry_span_log>
<!--
记录 ClickHouse 系统发生致命错误（fatal errors）时的堆栈跟踪信息。这个表通常是空的，只有在系统崩溃时才会填充数据。
崩溃后的调试: 通过分析 crash_log 表中的堆栈跟踪信息，开发者可以了解系统崩溃时的上下文，帮助定位和修复导致崩溃的问题。
崩溃监控: 对 crash_log 进行定期检查，可以帮助监控系统稳定性，及早发现潜在的严重问题。
日志表清理: 由于崩溃日志表可能长时间保持为空，当崩溃事件发生后，建议定期检查和清理该表中的数据，以免累积过多的历史崩溃信息。
性能影响: 尽管崩溃日志表的数据量较小，但频繁刷新操作可能对系统性能产生轻微影响。根据系统的实际崩溃频率，可以调整刷新间隔以优化性能。
-->
<crash_log>
<database>system</database>
<table>crash_log</table>
<!-- 指定分区策略，但在此配置中为空，意味着不对表进行分区。由于崩溃日志表通常包含的数据量较小，不需要分区管理。 -->
<partition_by />
<!-- 指定将内存中的崩溃日志数据刷新到磁盘的时间间隔（以毫秒为单位）。这里设置为 1000 毫秒（即每 1 秒刷新一次），以确保数据在崩溃时尽快写入磁盘。 -->
<flush_interval_milliseconds>1000</flush_interval_milliseconds>
<!-- 指定崩溃日志表中可以容纳的最大行数。这里设置为 1024 行，这对于记录少量的崩溃信息是足够的。 -->
<max_size_rows>1024</max_size_rows>
<!-- 指定为崩溃日志数据预留的行数，与 max_size_rows 相同，设置为 1024 行。 -->
<reserved_size_rows>1024</reserved_size_rows>
<!-- 指定在后台自动刷新崩溃日志数据之前，内存中保留的行数阈值。这里设置为 512 行，意味着一旦日志行数达到 512，就会触发刷新操作。 -->
<buffer_size_rows_flush_threshold>512</buffer_size_rows_flush_threshold>
<!-- 这个选项指定在系统崩溃时是否强制将崩溃日志数据刷新到磁盘。设置为 true 时，即使在系统崩溃的情况下，也会尝试将数据保存，以避免数据丢失。 -->
<flush_on_crash>true</flush_on_crash>
</crash_log>
<!--
记录用户登录和登出事件的日志配置项。虽然它可以帮助追踪用户的登录行为，但由于存在已知的安全问题，不建议在生产环境中使用。
用户行为追踪: 可以通过记录用户的登录和登出事件，了解用户的使用习惯和系统负载情况。
安全监控: 通过分析会话日志，可以发现异常的登录行为，比如频繁的登录失败尝试，帮助识别潜在的安全威胁。
已知的安全问题: session_log 由于存在安全漏洞，在生产环境中使用可能会带来安全风险，因此通常不建议启用。如果有用户行为追踪需求，应考虑替代方案。
性能影响: 频繁的日志记录和刷新操作可能对系统性能产生影响，特别是在高并发情况下。
可用性: 该配置项通常默认是被注释掉的，除非明确需要并且可以确保系统的安全性，否则建议保持其禁用状态。
-->
<!-- <session_log>
<database>system</database>
<table>session_log</table>
<partition_by>toYYYYMM(event_date)</partition_by>
<flush_interval_milliseconds>7500</flush_interval_milliseconds>
<max_size_rows>1048576</max_size_rows>
<reserved_size_rows>8192</reserved_size_rows>
<buffer_size_rows_flush_threshold>524288</buffer_size_rows_flush_threshold>
<flush_on_crash>false</flush_on_crash>
</session_log> -->
<!--
记录 ClickHouse 中处理器级别的性能分析数据。这些日志数据可以帮助用户了解查询在执行过程中，各个处理器的性能表现，以便于进行性能调优和故障排查。
性能调优: 通过分析处理器级别的性能数据，可以识别出性能瓶颈，优化查询和数据处理流程。
故障排查: 当系统出现性能问题时，处理器性能日志可以帮助定位问题发生的具体环节，为修复问题提供数据支持。
资源管理: 了解不同处理器在查询执行中的表现，可以帮助合理分配系统资源，提升整体效率。
启用 processors_profile_log 可以在进行系统调优时提供详尽的数据支持，但也会增加系统的存储和处理开销。因此，建议在需要深入分析性能时启用该功能，并且在日常生产环境中谨慎使用。
-->
<processors_profile_log>
<database>system</database>
<table>processors_profile_log</table>
<partition_by>toYYYYMM(event_date)</partition_by>
<flush_interval_milliseconds>7500</flush_interval_milliseconds>
<max_size_rows>1048576</max_size_rows>
<reserved_size_rows>8192</reserved_size_rows>
<buffer_size_rows_flush_threshold>524288</buffer_size_rows_flush_threshold>
<flush_on_crash>false</flush_on_crash>
</processors_profile_log>
<!--
异步插入日志
用于记录异步插入操作的日志表。这个日志允许用户检查在“fire-and-forget”模式下插入查询的状态。
异步插入状态监控: 在 ClickHouse 中进行异步插入操作时，可以通过该日志检查插入操作的执行状态和结果。这对于需要批量处理数据但不希望等待插入完成的场景非常有用。
性能分析: 记录异步插入的操作日志有助于分析和调优数据插入的性能，帮助识别潜在的瓶颈。
故障排查: 当异步插入操作出现问题时，日志可以提供详细的上下文信息，帮助快速定位和解决问题。
启用 asynchronous_insert_log 可以为异步插入操作提供有价值的状态信息，尤其在处理大批量数据插入时非常有用。不过，这也会增加系统的日志存储需求，因此建议根据实际需求配置日志保留时间 (ttl) 以平衡存储资源。
-->
<asynchronous_insert_log>
<database>system</database>
<table>asynchronous_insert_log</table>
<flush_interval_milliseconds>7500</flush_interval_milliseconds>
<max_size_rows>1048576</max_size_rows>
<reserved_size_rows>8192</reserved_size_rows>
<buffer_size_rows_flush_threshold>524288</buffer_size_rows_flush_threshold>
<flush_on_crash>false</flush_on_crash>
<!-- 指定如何对异步插入日志表进行分区管理。配置中按 event_date 进行分区，这有助于管理和查询日志数据。 -->
<partition_by>event_date</partition_by>
<!-- 设置日志数据的保留时间。这里配置为 event_date + INTERVAL 3 DAY，意味着日志数据会在创建后的 3 天后被删除。 -->
<ttl>event_date + INTERVAL 3 DAY</ttl>
</asynchronous_insert_log>
<!-- ============================================================================================================================================================== -->
<!-- ================================================================ 可以理解为 ck 的扩展支持配置 ==================================================================== -->
<!-- ============================================================================================================================================================== -->
<!-- 设置 ClickHouse 存储顶级域名（Top-Level Domains，TLD）的路径。通常情况下，ClickHouse 不会直接使用此配置项 -->
<!-- <top_level_domains_path>/var/lib/clickhouse/top_level_domains/</top_level_domains_path> -->
<!-- Custom TLD lists.
Format: <name>/path/to/file</name>
Changes will not be applied w/o server restart.
Path to the list is under top_level_domains_path (see above).
-->
<top_level_domains_lists>
<!--
<public_suffix_list>/path/to/public_suffix_list.dat</public_suffix_list>
-->
</top_level_domains_lists>
<!--
设置 ClickHouse 外部字典的配置文件路径。外部字典可以帮助你将外部数据源（如文件、数据库等）集成到 ClickHouse 中，从而可以在查询中使用这些外部数据。ClickHouse 将根据这个模式加载所有匹配的字典配置文件。
https://clickhouse.com/docs/en/sql-reference/dictionaries/external-dictionaries/external-dicts
文件路径模式: *_dictionary.*ml 是一个文件路径模式，表示所有以 _dictionary 结尾的文件，并且扩展名为 .ml（ClickHouse 使用的字典配置文件扩展名）都会被加载。这允许你将多个字典配置文件组织在一个目录中，并通过统一的配置项进行加载。
配置文件格式: 外部字典配置文件通常以 XML 或 JSON 格式存在，定义了字典的源、结构、更新策略等信息。
配置示例: 假设你在 /etc/clickhouse-server/dictionaries/ 目录下有如下文件：
user_dictionary.xml
product_dictionary.xml
使用 <dictionaries_config> 配置项可以确保这些文件被 ClickHouse 加载，而不需要在配置中逐个列出每个文件。
注意事项
路径有效性: 确保路径模式指向的目录是存在的，并且包含了正确格式的字典配置文件。
权限: ClickHouse 进程需要有权限读取这些配置文件。
配置更新: 如果外部字典配置文件发生变化，通常需要重新加载配置，或者重启 ClickHouse 以使更改生效。
-->
<dictionaries_config>*_dictionary.*ml</dictionaries_config>
<!--
用于指定用户定义的可执行函数的配置文件路径模式。这使你能够扩展 ClickHouse 的功能，添加自定义的函数，并将这些函数与 ClickHouse 查询引擎集成。
文件路径模式: *_function.*ml 是一个文件路径模式，表示所有以 _function 结尾的文件，并且扩展名为 .ml（ClickHouse 使用的函数配置文件扩展名）都会被加载。这允许你将多个函数配置文件组织在一个目录中，并通过统一的配置项进行加载。
配置文件格式: 用户定义的可执行函数配置文件通常以 XML 或 JSON 格式存在，定义了函数的名称、实现、参数等信息。这些文件中包含了如何实现和使用自定义函数的详细信息。
配置示例: 假设你在 /etc/clickhouse-server/functions/ 目录下有如下文件：
custom_function.xml
advanced_function.xml
使用 <user_defined_executable_functions_config> 配置项可以确保这些文件被 ClickHouse 加载，而不需要在配置中逐个列出每个文件。
注意事项
路径有效性: 确保路径模式指向的目录是存在的，并且包含了正确格式的函数配置文件。
权限: ClickHouse 进程需要有权限读取这些配置文件。
配置更新: 如果用户定义的函数配置文件发生变化，通常需要重新加载配置，或者重启 ClickHouse 以使更改生效。
-->
<user_defined_executable_functions_config>*_function.*ml</user_defined_executable_functions_config>
<!--
ZooKeeper中存放CREATE FUNCTION命令创建的自定义SQL函数的路径。如果没有指定，它们将存储在本地。
指定在 ZooKeeper 中存储用户定义的 SQL 函数的位置。这对于在分布式环境中存储和共享用户定义的函数非常有用。
ZooKeeper 存储路径: 指定的路径是 ZooKeeper 中的一个节点路径，ClickHouse 将在该路径下存储用户定义的 SQL 函数。这有助于在多台服务器上共享和管理这些函数。
默认行为: 如果不设置 <user_defined_zookeeper_path>，则用户定义的 SQL 函数会被存储在 ClickHouse 服务器的本地文件系统中。这可能会导致在分布式环境中管理和同步这些函数变得复杂。
路径示例: 上述示例将用户定义的 SQL 函数存储在 ZooKeeper 的 /clickhouse/user_defined 路径下。这样做的好处是，当 ClickHouse 集群中的多个节点需要访问相同的用户定义函数时，它们可以从 ZooKeeper 中读取和共享这些函数。
注意事项:
ZooKeeper 配置: 确保你的 ClickHouse 集群已正确配置了 ZooKeeper，并且路径在 ZooKeeper 中是可写的。
路径一致性: 在分布式环境中，确保所有 ClickHouse 节点都指向相同的 ZooKeeper 路径，以保持函数的一致性。
权限和安全性: 确保 ZooKeeper 节点的权限设置正确，以防止未授权的访问或修改。
-->
<!-- <user_defined_zookeeper_path>/clickhouse/user_defined</user_defined_zookeeper_path> -->
<!--
如果您希望数据被压缩30-100%，取消注释。如果你刚开始使用ClickHouse，就不要这么做。
指定ClickHouse 中数据的压缩方法，从而有效减少存储空间。根据你的配置，它可以显著提高数据的压缩比，但可能会增加 CPU 使用率。
compression: 这是一个压缩配置的容器，用于定义数据压缩的相关设置。
case: 允许你定义多个条件，来决定何时使用特定的压缩方法。配置中的条件必须全部满足才会应用对应的压缩方法。若没有匹配的条件，则使用默认的 lz4 压缩方法。
min_part_size: 定义数据分区的最小大小（以字节为单位），只有当数据分区大小大于此值时，压缩方法才会被应用。上面的配置中设置为 10000000000 字节（即 10 GB）。
min_part_size_ratio: 定义数据分区相对于整个表大小的最小比例。只有当分区大小相对于表大小大于此比例时，压缩方法才会被应用。上面的配置中设置为 0.01（即 1%）。
method: 指定使用的压缩方法。在上面的配置中，选择了 zstd（Zstandard），这是一种高效的压缩算法，通常可以提供比 lz4 更好的压缩比，但可能会增加 CPU 使用量。
压缩效率: 使用 zstd 压缩方法通常可以显著提高压缩比，节省存储空间。相较于 lz4，zstd 提供了更高的压缩率，但可能会带来更高的解压缩开销。
性能考虑: 在选择压缩方法时，需要权衡存储空间节省和 CPU 使用率。zstd 压缩方法可能需要更多的计算资源，这可能会影响到 ClickHouse 的性能。
应用场景: 如果你的 ClickHouse 环境刚刚启动并且数据量较小，建议先不要启用高级压缩配置。等到系统运行稳定，数据量增加后，再考虑启用压缩。
调整和测试: 可以根据你的具体使用情况调整 min_part_size 和 min_part_size_ratio 的值，进行性能测试，以找到最适合你的环境的配置。
-->
<!--
<compression>
<!- - 一系列cese，按顺序检查。最后一个匹配的案例获胜。如果没有匹配，将使用lz4。 - ->
<case>
<!- - Conditions. 一切都必须得到满足. 有些条件可以省略。- ->
<min_part_size>10000000000</min_part_size> <!- - 定义数据分区的最小大小（以字节为单位） - ->
<min_part_size_ratio>0.01</min_part_size_ratio> <!- - 定义数据分区相对于整个表大小的最小比例 - ->
<!- - 指定使用的压缩方法 - ->
<method>zstd</method>
</case>
</compression>
-->
<!--
加密配置。服务器执行命令。如果这样的命令是在启动时获取加密密钥定义，否则加密编解码器将被禁用。这命令通过/bin/sh执行，预计写入标准输出的 Base64 编码密钥。
为 ClickHouse 设置数据加密的方法。此配置确保在数据传输或存储时能够进行加密保护，以提升数据安全性。
encryption_codecs: 这是配置加密编解码器的容器。
key_hex: 用于定义加密密钥。密钥需要以十六进制格式提供，并且长度必须为 16 字节（128 位），这是 aes_128_gcm_siv 加密方法所要求的。
from_env: 从环境变量中获取密钥的配置。例如，可以从系统环境变量中提取密钥值。
id=: 用于指定不同密钥的 ID。可以配置多个密钥，并设置当前使用的密钥 ID。
key: 直接在配置文件中指定密钥值（以十六进制格式）。
current_key_id: 指定当前正在使用的密钥的 ID。这对于多个密钥的配置非常重要，可以确保使用正确的密钥进行加密和解密。
nonce: 可选配置，用于定义加密时使用的随机数（nonce）。aes_128_gcm_siv 算法使用 nonce 来确保每个加密操作的唯一性和安全性。
-->
<encryption_codecs>
<!-- aes_128_gcm_siv -->
<!-- 使用从环境变量获取的密钥 -->
<!-- the code should use this key and throw an exception if its length is not 16 bytes -->
<!--key_hex from_env="..."></key_hex -->
<!-- Example of multiple hex keys. They can be imported from env or be written down in config-->
<!-- the code should use these keys and throw an exception if their length is not 16 bytes -->
<!-- key_hex id="0">...</key_hex -->
<!-- key_hex id="1" from_env=".."></key_hex -->
<!-- key_hex id="2">...</key_hex -->
<!-- current_key_id>2</current_key_id -->
<!-- Example of getting hex key from config -->
<!-- the code should use this key and throw an exception if its length is not 16 bytes -->
<!-- key>...</key -->
<!-- example of adding nonce -->
<!-- nonce>...</nonce -->
<!-- /aes_128_gcm_siv -->
</encryption_codecs>
<!--
管理在 ClickHouse 集群中执行分布式 DDL（数据定义语言）操作的设置。这些操作包括(CREATE, DROP, ALTER, RENAME)等操作。要使用这些功能，需要启用 ZooKeeper，因为 ZooKeeper 用于协调和同步这些操作。
集群同步: 启用分布式 DDL 功能可以使集群中的所有节点同步执行 DDL 操作。这对于维护大型集群的一致性非常重要。
任务管理: 通过配置任务的最大存活时间、清理频率和队列容量，可以有效管理和优化 DDL 操作的执行和存储，防止任务积压和资源浪费。
性能优化: 配置 pool_size 允许你控制同时运行的 DDL 查询数量，从而优化集群的资源使用和性能。
故障恢复: 配置清理任务的 TTL 和清理延迟，可以帮助确保过期或无效的任务被及时清理，保持系统的健康状态。
建议
测试: 在生产环境启用此功能之前，建议在测试环境中进行验证，确保配置符合集群的需求并能正常工作。
监控: 监控 DDL 任务的执行和队列状态，以确保系统在高负载情况下能够正常运行。
优化: 根据集群的规模和负载，调整 pool_size 和 max_tasks_in_queue 设置，以优化 DDL 操作的执行性能。
-->
<distributed_ddl>
<!-- 在 ZooKeeper 中用于存储 DDL 任务队列的路径。该路径用于协调集群中所有节点的 DDL 操作 -->
<path>/clickhouse/task_queue/ddl</path>
<!-- 指定用于执行 DDL 查询的配置文件（profile）。可以通过此设置指定特定的配置文件，影响 DDL 操作的执行参数 -->
<!-- <profile>default</profile> -->
<!-- 控制同时可以运行多少个 ON CLUSTER 查询。这个参数定义了在集群中同时并发执行的 DDL 查询数量. -->
<!-- <pool_size>1</pool_size> -->
<!--
清理设置（活动任务不会被删除
-->
<!-- 控制任务的最大存活时间（以秒为单位）。默认情况下为 1 周（604800 秒）。超过这个时间的任务将被自动清除 -->
<!-- <task_max_lifetime>604800</task_max_lifetime> -->
<!-- 控制清理任务的频率（以秒为单位）。指定了多久执行一次任务清理操作 -->
<!-- <cleanup_delay_period>60</cleanup_delay_period> -->
<!-- 控制任务队列中可以存在的最大任务数量。如果队列满了，新任务将会被拒绝或等待 -->
<!-- <max_tasks_in_queue>1000</max_tasks_in_queue> -->
</distributed_ddl>
<!--
用于微调 MergeTree 表的设置。MergeTree 是 ClickHouse 最常用的表引擎之一，用于处理大量的时间序列数据和高写入负载的场景。请参阅源代码中的文档，位于 MergeTreeSettings.h
这个设置指定了在 MergeTree 表中，允许存在的最大数量的可疑损坏数据部分。如果发现超过这个数量的数据部分被标记为可疑损坏，系统可能会采取措施（例如停止合并或报告警告）以防止数据损坏或丢失。此设置有助于管理和优化 MergeTree 表的稳定性和数据完整性
在遇到可疑损坏的情况下，ClickHouse 可能会延迟或阻止某些操作（如数据合并），从而可能影响性能。调整此设置可以平衡数据完整性和系统性能。
-->
<!--
<merge_tree>
<max_suspicious_broken_parts>5</max_suspicious_broken_parts>
</merge_tree>
-->
<!--
Protection from accidental DROP.
If size of a MergeTree table is greater than max_table_size_to_drop (in bytes) than table could not be dropped with any DROP query.
If you want do delete one table and don't want to change clickhouse-server config, you could create special file <clickhouse-path>/flags/force_drop_table and make DROP once.
By default max_table_size_to_drop is 50GB; max_table_size_to_drop=0 allows to DROP any tables.
The same for max_partition_size_to_drop.
Uncomment to disable protection.
-->
<!--
保护机制配置，防止在 ClickHouse 中意外删除重要的大型表或分区。它们提供了一种保护机制，以避免误操作或不小心删除了大量的数据。
默认情况下，最大表大小为 50GB。设置为 0 允许删除任何表或分区，要禁用保护机制，请取消注释并将值设置为 0
max_table_size_to_drop: 这个设置定义了一个阈值，表示如果表的大小超过这个阈值（以字节为单位），则无法通过普通的 DROP 查询删除该表。默认值为 50GB。如果将其设置为 0，则可以删除任何大小的表。这个设置是为了保护大表免于被意外删除。
max_partition_size_to_drop: 这个设置定义了一个阈值，表示如果分区的大小超过这个阈值，则无法通过普通的 DROP PARTITION 查询删除该分区。默认值为 50GB。如果将其设置为 0，则可以删除任何大小的分区。
保护数据: 设置这些阈值可以防止意外删除大表或大分区，从而避免潜在的数据丢失或业务中断。
操作安全: 在进行删除操作时，设置这些阈值可以增加一层保护，确保删除操作不会无意中影响到重要的数据。
紧急操作: 如果确实需要删除超过这些阈值的表或分区，可以通过创建一个特殊文件 <clickhouse-path>/flags/force_drop_table 来强制执行删除操作。这需要额外的步骤，增加了一层安全防护。
-->
<!-- <max_table_size_to_drop>0</max_table_size_to_drop> -->
<!-- <max_partition_size_to_drop>0</max_partition_size_to_drop> -->
<!--
GraphiteMergeTree 是 ClickHouse 的一种表引擎，用于处理 Graphite 监控数据。下面的配置示例展示了如何为 GraphiteMergeTree 表引擎设置数据汇总（rollup）策略。这种策略能够将高精度的数据聚合为较低精度的数据，从而有效地减少存储需求。
-->
<graphite_rollup_example>
<pattern>
<!-- 正则表达式，用于匹配特定的 Graphite 指标名称，对于符合正则表达式 "click_cost" 的数据使用特定的汇总策略 -->
<regexp>click_cost</regexp>
<!-- 用于聚合匹配的数据的函数。例如，any 表示选取任意一个值。 -->
<function>any</function>
<retention>
<!-- 数据保留的时间范围（以秒为单位）。 -->
<age>0</age>
<!-- 数据的精度（以秒为单位）。即汇总后数据的时间间隔。 -->
<precision>3600</precision>
</retention>
<retention>
<age>86400</age>
<precision>60</precision>
</retention>
</pattern>
<!-- 默认的汇总策略 -->
<default>
<!-- 默认的聚合函数。如果没有具体的匹配模式，则使用此函数。 -->
<function>max</function>
<retention>
<age>0</age>
<precision>60</precision>
</retention>
<retention>
<age>3600</age>
<precision>300</precision>
</retention>
<retention>
<age>86400</age>
<precision>3600</precision>
</retention>
</default>
</graphite_rollup_example>
<!--
Directory in <clickhouse-path> containing schema files for various input formats.The directory will be created if it doesn't exist.
目录路径: /var/lib/clickhouse/format_schemas/ 是用于存储输入格式模式文件的目录。ClickHouse 会在启动时检查这个目录，如果不存在，则会自动创建。
用途: 输入格式模式文件定义了如何解析和处理特定的数据格式，例如 CSV、JSON、XML 等。ClickHouse 使用这些文件来确保数据以正确的格式被读取和解析。
-->
<format_schema_path>/var/lib/clickhouse/format_schemas/</format_schema_path>
<!--
默认查询屏蔽规则，匹配的行将被日志中的其他内容替换，以隐藏日志中敏感的数据，（包括文本日志和 system.query_log）
name - 规则名称（可选）
regexp - RE2 兼容的正则表达式（必需）
replace - 替换敏感数据的字符串（可选，默认为六个星号）
<query_masking_rules>
<rule>
<name>hide encrypt/decrypt arguments</name>
<regexp>((?:aes_)?(?:encrypt|decrypt)(?:_mysql)?)\s*\(\s*(?:'(?:\\'|.)+'|.*?)\s*\)</regexp>
<replace>\1(???)</replace>
</rule>
</query_masking_rules> -->
<!--
取消注释以使用自定义 http 处理程序。
规则按从上到下的顺序检查，第一个匹配的规则将运行处理程序
url - 匹配请求 URL，你可以使用 'regex:' 前缀来使用正则表达式匹配（可选）
methods - 匹配请求方法，你可以使用逗号分隔多个方法匹配（可选）
headers - 匹配请求头，每个子元素是头部名称，你可以使用 'regex:' 前缀来使用正则表达式匹配（可选）
handler 是请求处理程序
type - 支持的类型: static, dynamic_query_handler, predefined_query_handler
query - 使用 predefined_query_handler 类型时，处理程序被调用时执行的查询
query_param_name - 使用 dynamic_query_handler 类型时，从 HTTP 请求参数中提取并执行的值
status - 使用 static 类型时，响应状态码
content_type - 使用 static 类型时，响应的内容类型
response_content - 使用 static 类型时，发送给客户端的响应内容，当使用 'file://' 或 'config://' 前缀时，从文件或配置中找到内容并发送给客户端。
<http_handlers>
<rule>
<url>/</url>
<methods>POST,GET</methods>
<headers><pragma>no-cache</pragma></headers>
<handler>
<type>dynamic_query_handler</type>
<query_param_name>query</query_param_name>
</handler>
</rule>
<rule>
<url>/predefined_query</url>
<methods>POST,GET</methods>
<handler>
<type>predefined_query_handler</type>
<query>SELECT * FROM system.settings</query>
</handler>
</rule>
<rule>
<handler>
<type>static</type>
<status>200</status>
<content_type>text/plain; charset=UTF-8</content_type>
<response_content>config://http_server_default_response</response_content>
</handler>
</rule>
</http_handlers>
-->
<!-- 崩溃报告配置 -->
<send_crash_reports>
<!-- 修改 <enabled> 为 true 允许将崩溃报告发送到 ClickHouse 核心开发团队，使用 Sentry https://sentry.io 在预生产环境中启用此功能是非常有帮助的-->
<enabled>false</enabled>
<!-- 修改 <anonymize> 为 true，如果您不希望将服务器主机名附加到崩溃报告中，如果担心公开主机名，可以将 <anonymize> 设置为 true 以保护隐私。-->
<anonymize>false</anonymize>
<!-- 如果你有自己的 Sentry 实例或使用其他工具进行调试，可以修改 <endpoint> 为你自己的 DSN。 -->
<!-- some in-house engineers or hired consultants who're going to debug ClickHouse issues for you -->
<endpoint>https://6f33034cfe684dd7a3ab9875e57b1c8d@o388870.ingest.sentry.io/5226277</endpoint>
</send_crash_reports>
<!--
取消注释以禁用 ClickHouse 内部 DNS 缓存，1: 禁用 ClickHouse 内部的 DNS 缓存功能。 0 或 未定义: 启用内部 DNS 缓存功能。
禁用缓存: 如果你需要确保 ClickHouse 每次都进行 DNS 查询（例如，在 DNS 配置频繁变化的环境中），可以启用此选项。
性能: 启用 DNS 缓存通常可以提高性能，因为它减少了 DNS 查询的次数，避免了每次都进行网络请求。
配置更改: 更改此设置后，需要重新启动 ClickHouse 服务器以使更改生效。
-->
<!-- <disable_internal_dns_cache>1</disable_internal_dns_cache> -->
<!--
你还可以像这样配置rocksdb，RocksDB 是一种用于存储数据的嵌入式数据库，ClickHouse 可以使用它作为存储引擎
rocksdb：RocksDB 的配置块。
options：指定 RocksDB 的通用选项。
max_background_jobs：设置后台作业的最大数量。在这里设置为 8，意味着 RocksDB 可以同时运行最多 8 个后台作业。
column_family_options：指定列族（Column Family）的选项。
num_levels：设置列族的层级数。在这里设置为 2，表示使用 2 层级结构来管理存储的数据。
tables：为每个表单独指定 RocksDB 的配置。
table：定义一个表的 RocksDB 配置。
name：表的名称。可以为特定的表指定单独的 RocksDB 配置。
options：指定表的通用选项。
max_background_jobs：与全局设置类似，设置该表的最大后台作业数。
column_family_options：为该表指定列族的选项。
num_levels：设置该表列族的层级数。
-->
<!--
<rocksdb>
<options>
<max_background_jobs>8</max_background_jobs>
</options>
<column_family_options>
<num_levels>2</num_levels>
</column_family_options>
<tables>
<table>
<name>TABLE</name>
<options>
<max_background_jobs>8</max_background_jobs>
</options>
<column_family_options>
<num_levels>2</num_levels>
</column_family_options>
</table>
</tables>
</rocksdb>
-->
<!--
设置 ClickHouse 的查询缓存。查询缓存可以存储查询结果，以便于重复执行相同查询时快速返回结果，从而提高性能
这些配置项共同控制查询缓存的容量和大小限制，以便在提高查询性能的同时避免缓存过度占用内存。
-->
<query_cache>
<!-- 缓存的最大总大小，以字节为单位。在这里设置为 1073741824 字节，即 1 GB。这意味着查询缓存的总容量不会超过 1 GB。 -->
<max_size_in_bytes>1073741824</max_size_in_bytes>
<!-- 缓存中允许的最大条目数。在这里设置为 1024，表示缓存中最多可以存储 1024 个查询结果。 -->
<max_entries>1024</max_entries>
<!-- 缓存中每个条目的最大大小，以字节为单位。在这里设置为 1048576 字节，即 1 MB。这意味着每个查询结果的最大缓存大小为 1 MB。 -->
<max_entry_size_in_bytes>1048576</max_entry_size_in_bytes>
<!-- 缓存中每个条目的最大行数。在这里设置为 30000000 行，即 3000 万行。这意味着每个查询结果的最大行数为 3000 万行。 -->
<max_entry_size_in_rows>30000000</max_entry_size_in_rows>
</query_cache>
<!--
当 ClickHouse 发生崩溃或出现严重错误时，系统会生成堆栈跟踪（Stack Trace）管理员可以选择是否在这些堆栈跟踪中显示内存地址。将其设置为 false 可以隐藏这些地址，从而减少泄露潜在敏感信息的风险。
生产环境：如果你对安全性非常敏感，可以考虑禁用地址显示。然而，建议在启用此选项前确保有其他调试手段，以应对可能的调试困难。（很难调试）
-->
<!-- This allows to disable exposing addresses in stack traces for security reasons.
Please be aware that it does not improve security much, but makes debugging much harder.
The addresses that are small offsets from zero will be displayed nevertheless to show nullptr dereferences.
Regardless of this configuration, the addresses are visible in the system.stack_trace and system.trace_log tables
if the user has access to these tables.
I don't recommend to change this setting.
<show_addresses_in_stack_traces>false</show_addresses_in_stack_traces>
-->
<!--
oom_score 是 Linux 系统中一个用于控制 OOM（Out-Of-Memory）杀手行为的参数。Linux 在内存耗尽时会选择性地终止一些进程，以释放内存，防止系统崩溃。oom_score 值范围是从 -1000 到 1000，用于指定某个进程在 OOM 情况下被终止的优先级。
值为 -1000 表示该进程被系统终止的可能性最小，而 1000 表示最有可能被终止。如果未指定，默认情况下，Linux 系统会根据进程的内存使用情况自动分配一个 oom_score。
使用建议：
内存有限的环境：如果 ClickHouse 是系统中的关键服务，可以将 oom_score 设置为 -1000，以防止它被 OOM 杀手终止。
内存充裕的环境：可以保持默认设置，或根据具体需求调整 oom_score，确保在内存资源紧张时，系统能够更合理地管理进程终止顺序。
-->
<!-- On Linux systems this can control the behavior of OOM killer.
<oom_score>-1000</oom_score>
-->
</clickhouse>
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
