每月几亿行数据账单失控？ClickHouse 实时数仓部署与资源规划实战

几亿行数据背后，账单到底贵在哪

每月几亿行数据，传统云数仓账单太贵，ClickHouse 到底省在哪、又贵在哪？这个问题在用户行为分析、实时业务大盘、广告报表这些场景里被反复提起。很多团队一开始是被按量计费、存储与计算绑定、冷数据也要按热价格付费的模式拖垮预算的：事件流源源不断地写入，查询并发一上来，弹性扩容的单价就被放大，月度账单常常超出预期数倍。

把账算清楚之前，先要承认一个前提：ClickHouse 不是"免费的万能替换"，它是用列式存储、向量化执行和稀疏索引换来了极高的单节点吞吐，省下的是扫描与聚合的计算成本；但代价是它对写入模式、表结构设计和运维成熟度有要求，"省"和"贵"往往出现在不同的环节。本文不谈抽象概念，直接按部署和资源规划的步骤拆开看：什么场景该上、分区怎么设计、物化视图怎么落地、并发怎么估内存、冷热存储怎么分、账单到底怎么控制。

需要强调的是，本文讨论的部署与资源规划结论，均以 ClickHouse 官方文档的引擎与配置说明为基准，具体版本差异与实时定价请以官方实时文档为准。不同业务的数据特征差异极大，下文给出的节点数、内存、并发参数都属于规划参考区间，落地前务必结合真实查询画像做压测。

为什么账单会失控：成本结构的三处错位

传统云数仓的计费通常把"存储、计算、出口"打包在一起，数据量增长时三项同时上涨。ClickHouse 的省法来自三处结构差异，也正是这三处容易让人误判。

其一，计算与存储的解耦程度。ClickHouse 把数据压实成列存 part，查询时只读取涉及列和命中的稀疏索引粒度（granule），一次聚合扫描的原始行数远低于行存数据库；这意味着同样几亿行，ClickHouse 完成大盘查询消耗的 CPU 时间更短，弹性时长更短，计费窗口更小。

其二，冷热分层的能力。ClickHouse 支持基于存储策略（storage policy）的卷（volume）与磁盘（disk）配置，可以把新写入、小块数据留在 SSD，合并后变大的 part 自动迁移到 HDD 或对象存储，按访问热度付费，而不是所有数据都按最贵那档存储计价。这对"热数据只占一小部分、历史明细要留很久"的事件分析场景尤其关键。

其三，预聚合的降本空间。通过物化视图在写入时就把高频聚合结果算好，查询命中聚合表后无需每次重扫原始行，单查询成本随数据量几乎不增长。换句话说，ClickHouse 的"省"是可设计的：你越是把它当实时 OLAP 数仓来规划，单位查询成本越低。

那"贵"在哪？贵在三点：一是对表结构设计的要求高，分区键、排序键、物化视图设计不当会让性能断崖式下跌，倒逼你加机器；二是高并发明细查询对内存的压力集中，内存配小了频繁触发内存上限报错，配大了硬件成本上升；三是集群化后的运维复杂度，分片、副本、ZooKeeper（或 Keeper）依赖都会带来隐性成本。把这三处看明白，才知道钱该花在节点、内存还是存储上。

单机还是集群：什么业务真的需要多节点

不是所有场景都需要集群。ClickHouse 单机就能吃下很高的写入与查询吞吐，是否上集群，取决于三个硬约束：数据规模是否超过单机存储与内存上限、查询并发是否超过单机 CPU 能并行处理的窗口、以及是否要求高可用与故障容错。

如果每天新增几千万行、保留数月、查询以时序聚合为主，单机大内存配多盘往往是最省的方案。单机内部已经通过向量化和多线程把一颗 CPU 用到极致，盲目分片反而增加跨节点通信和元数据管理的开销。

需要集群的典型信号有：单副本存储容量逼近磁盘上限，必须横向分片（shard）把数据摊开；业务大盘要求副本（replica）提供容错，单节点宕机不能中断报表；多个团队共享一套数仓，需要把不同业务或不同租户的数据按分片隔离，避免互相抢占资源。ClickHouse 的集群通过分片做水平扩展、通过副本做冗余，两者是正交的：分片解决容量与并发上限，副本解决可用性。规划时建议先按"容量+并发"定分片数，再按"可用性"定每分片的副本数，而不是反过来拍脑袋。

这里有个容量认知常被搞反：同一分片内的多个副本存的是完全相同的数据，所以副本提升的是可用性和读吞吐冗余，并不增加该分片的存储容量——一个分片单副本能存 10 TB，加两个副本还是 10 TB 总量，只是多了一份拷贝。真正决定总容量的永远是分片数 × 单分片容量。因此"数据快放不下了"应当加的是分片，"怕单点宕机"才加副本。混为一谈的结果，要么是容量没解决、要么是为冗余付了不必要的存储双倍成本。副本之间的元数据与复制队列由 Keeper 协调，复制采用异步模式，正常网络下副本间延迟很低，但跨可用区部署时要为复制带宽与一致性窗口单独留出余量。

还有一个常被忽略的点：副本的同步依赖协调服务（ClickHouse Keeper 或 ZooKeeper）来记录 part 元数据与复制队列。节点越多，Keeper 的写入压力与一致性开销越大，因此集群规模往上有边界，不是线性加机器就线性加能力。超出一定规模后，更现实的做法是按业务域拆成多个逻辑集群，而不是单集群无限扩张。

MergeTree 分区键：别把"按天"当成银弹

分区是 ClickHouse 里最容易被设计错的一项。官方文档对分区键的结论非常直接：大多数情况下你并不需要分区键；即便需要，通常也不需要比"按月"更细的粒度，除非是可观测性这类按天分区很常见的场景。过度细分分区是明确的反模式。

分区的作用不是加速查询——真正加速查询的是 ORDER BY 排序键（它生成主键索引和稀疏索引）。分区只做一件事：按分区裁剪（partition pruning）减少需要打开的 part 数量，并让数据按时间或类别的逻辑边界更容易整块删除、移动、TTL 清理。因此分区键应当选择"查询经常用它做范围过滤、且基数适中"的维度。

对海量事件分析，最常见的合理选择是按事件时间分区，例如 PARTITION BY toYYYYMM(event_time) 按月，或者可观测性场景 PARTITION BY toDate(event_time) 按天。关键约束有两条：一是分区总数不要超过约一千个，否则文件系统里 part 文件和打开的文件描述符过多，SELECT 性能反而会变差；二是绝对不要用客户端标识、用户 ID、设备名这类高基数字段做分区键。正确做法是将这类高基数维度放进 ORDER BY 表达式的靠前位置（排序列首位），利用排序键索引来加速过滤，而不是拿来分区。

对于"多租户 SaaS"这类业务，分区键可以按"时间+租户"的元组设计，例如 PARTITION BY (toYYYYMM(event_time), tenant_id)，前提是租户数量可控、不会让分区数爆炸。更稳妥的折中是：分区只按时间，ORDER BY 把 tenant_id 放在排序键首位，这样单租户查询既能借助稀疏索引裁剪，又不会把分区数撑爆。分区键本质是"管理边界"，不是"查询加速键"，这个认知决定了后面所有性能调优的方向。

物化视图：把聚合成本从查询时挪到写入时

物化视图（Materialized View）是 ClickHouse 实时数仓降本的核心武器，但很多人把它理解成"普通视图的加速版"，这是误解。ClickHouse 的物化视图本质是一张独立的目标表加上一个写入触发器：当源表插入新数据时，视图定义里的 SELECT 会自动执行并把结果写入目标表，查询时直接读这张已经聚合好的表。

官方推荐的 rollup 模式由三个对象组成：原始明细表（MergeTree）、聚合表（通常用 AggregatingMergeTree 引擎）、以及连接两者的物化视图。聚合表不直接存最终数值，而是存"聚合状态"（AggregateFunction 类型），比如 uniqExactState(user_id)、sumState(value)、countState()，这些状态可以被后续合并。典型写法是：

源表用 PARTITION BY toYYYYMM(event_time) ORDER BY (event_time, user_id)，并配合 LowCardinality(String) 节省分类维度的内存；聚合表用 ENGINE = AggregatingMergeTree，按 toStartOfHour(event_time) 做小时级 bucket；物化视图在插入源表时自动按 bucket、国家、事件类型做 GROUP BY，把状态写入聚合表。最终查询时用 uniqExactMerge、sumMerge、countMerge 把状态合并成结果，或直接 SELECT ... FINAL 拿到最终值。

这个模式的降本逻辑很清楚：如果你的报表绝大多数都是"按小时/天聚合的 PV、UV、求和、均值"，那它们永远只命中聚合表，原始明细表只用于少数明细下钻。原始表哪怕涨到几十亿行，大盘查询扫描的也只是聚合后小几个数量级的数据。粒度选择要和最常见的分析窗口对齐——大多数查询看小时级就够，就不必预聚合到分钟；如果同时存在分钟级监控和天级报表，可以建多级物化视图（分钟→小时→天）形成 rollup 链。

一个容易被忽略的工程细节是：新建物化视图时，它默认只处理创建之后插入的新数据，不会自动回灌源表里已有的历史行。如果希望历史数据也进入聚合表，需要显式用 POPULATE 或在视图建好后手动跑一次 INSERT … SELECT 把存量补进去。但要注意 POPULATE 自身有窗口风险——它在执行背景 SELECT 期间新写入的源表数据可能既被 SELECT 覆盖又被实时视图重复处理，造成重复计数。因此生产环境更稳妥的做法是：先不带 POPULATE 建视图，再在业务低峰期用一次性回填把历史聚合补齐，并确认回填与实时写入之间没有时间重叠。这步没做对，报表早期会出现数据缺失或翻倍，排查成本不低。

需要提醒的是，物化视图增加的是写入侧的计算和存储开销：每写入一条明细，都要额外算一遍聚合状态并落盘。因此它对"写多读少、查询高度规律"的场景回报最高，对"查询高度随意、几乎每次都不同维度"的即席分析回报有限。落地前应当盘点真实查询画像，把高频、固定的聚合前置，而不是对所有维度都铺物化视图，否则写入放大和存储膨胀会反噬成本。

并发查询怎么估内存与 CPU：从配置项反推容量

高并发是实时业务大盘的常态，而 ClickHouse 的并发成本不是拍脑袋给个"支持多少 QPS"就能定下来的，它有一组明确的配置项可以反推资源。核心要分清三层作用域：单查询并行度（max_threads）、单查询内存（max_memory_usage）、以及服务端准入与线程调度（并发上限、软线程限制）。

max_threads 控制一个查询能用多少处理线程，默认值等于 ClickHouse 可用的硬件线程数（即 CPU 核心数）；在少于 32 核且开启超线程的 x86 上，默认会用逻辑核数（物理核的两倍）。它的含义是：把扫描、WHERE 过滤、GROUP BY 预聚合这些同阶段操作并行起来。值越小内存消耗越低，值越大大扫描类查询越快。官方建议不要无脑把 max_threads 设成 1 或 2，而是针对真实查询组合在 1、2、4 以及部署默认值之间实测，选能满足尾延迟和总吞吐的那个。26.5 版本起还有 max_threads_min_free_memory_per_thread（默认约 1 GiB），当服务器空闲内存不足时自动下调 max_threads，避免高并行查询集体撞内存上限。

max_memory_usage 限制单查询在单节点上使用的内存，设为 0 表示不限（无论自建还是云都如此）。这个值必须基于每类查询实测的峰值内存来定，并留数据增长与参数波动的余量：太低会把正常流量变成查询失败，太高则允许多个昂贵查询一起把节点内存吃光。单查询内存限制并不能控制跨并发查询的聚合内存，所以还要配合 max_memory_usage_for_user（单用户聚合内存）和 max_server_memory_usage（服务端总内存，常见调优参考为物理内存的 60%–80%）一起设。另有 max_concurrent_queries、max_concurrent_select_queries 等准入控制：达到上限后，新查询最多等待 queue_max_wait_ms（默认 0 即不等待），超时则报 TOO_MANY_SIMULTANEOUS_QUERIES。跨并发的线程软限制由 concurrent_threads_soft_limit_ratio_to_cores 控制，默认 2，即软上限约为 CPU 核数的两倍。

据此可以建立一个简单的资源反推思路：先按单类查询实测峰值内存设定 max_memory_usage，再按 max_server_memory_usage 留出服务端总内存池，用"单查询内存 × 期望并发数 × 安全系数"反推节点需要的总内存；CPU 侧则在"单查询 max_threads = 核数"和"软线程上限 = 2×核数"之间，根据查询是重扫描还是轻点查来定节点核数。这串数字不是拍出来的，而是每一档都要用真实查询混合去压测校准，所有具体阈值以官方实时文档为准。

热数据 SSD 冷数据 HDD：分层存储的逻辑

存储选型是 ClickHouse 成本控制的另一块大头。它原生支持多磁盘、多卷、多存储策略，可以在表级指定 storage_policy，把数据自动在 SSD 与 HDD（或对象存储）之间搬运，而不是所有数据都按最贵的 SSD 计价。

机制上有两条路径。一条是基于 part 大小的自动迁移：在存储策略里为热卷（SSD）设置 max_data_part_size_bytes，合并后预期超过该大小的 part 会直接写进下一个冷卷（HDD）；同时用 move_factor（默认 0.1，即某卷可用空间低于 10% 时触发）控制整体水位迁移。另一条是基于 TTL 的定时迁移：在表上定义 TTL 规则，例如 TTL event_time + INTERVAL 90 DAY TO DISK 'hdd'，超过保留期的 part 自动从 SSD 搬到 HDD 甚至对象存储。还有一个细节 perform_ttl_move_on_insert：默认开启时，插入时若数据已触发 TTL 迁移规则会立刻搬走，若目标盘很慢（如对象存储）可能拖慢写入，必要时可关闭让数据先落默认卷再后台迁移。

选型逻辑的本质是"按访问频率付费"：今天要被高频查询的当期数据留在 SSD，保证大盘和即席查询的低延迟；几个月前的历史明细、合规留存、低频下钻数据下沉到 HDD 或对象存储，单位存储成本显著下降。但要注意，HDD 上的 part 不合并（prefer_not_to_merge 官方明确不建议开启），慢盘上的后台 merge 和 TTL 移动会占用 I/O，所以冷卷的吞吐规划要单独留余量，不能简单地把 HDD 当成"便宜的 SSD"来用。另外网络盘、对象存储的延迟与吞吐特性差异很大，是否纳入分层要在真实读写比下评估，不宜凭直觉决定。

成本拆解：钱到底该花在节点、内存还是存储

把前面的环节串起来，就能回答开头的问题——ClickHouse 到底省在哪、又贵在哪。省的是"单位查询的计算成本"和"冷数据存储的单位价格"：列式压实、稀疏索引、物化视图前置聚合，让同样几亿行的大盘查询消耗的算力大幅下降；冷热分层让历史数据不必全按热价格付费。贵的是"达到目标并发所需的内存与 CPU"，以及"把表结构和物化视图设计对的人力与试错成本"。

在资源采购的优先级上，一万网络的建议是先把钱花在"匹配查询画像的内存"上：多数实时大盘的性能瓶颈不是磁盘而是内存——并发一高，每个查询都要吃一段内存，内存不足就会触发上限报错或被迫串行化，吞吐反而塌掉。因此与其盲目堆节点数，不如先把单节点的内存配到能容纳"单查询峰值 × 期望并发 × 安全系数"的水平。存储方面则按热数据比例决定 SSD 占比，热数据占比低的业务完全可以大头用 HDD 或对象存储，只在热卷留足 SSD，这比全 SSD 阵列省钱得多。

作为一家扎根基础设施服务的团队，一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时或咨询确认为准。在 ClickHouse 这类对单节点算力密度和本地磁盘 I/O 敏感的 OLAP 场景里，机型的 CPU 核数、内存通道数与磁盘类型（NVMe SSD 还是 SATA SSD、是否配 HDD 大容量卷）直接决定单节点能扛的并发与容量上限，因此采购时应以"核数—内存—磁盘分层"为一组参数整体评估，而不是单独比某一项单价。需要补充的是，节点之间的数据复制与协调服务会产生跨节点通信，网络质量会影响副本同步与跨分片查询的尾延迟，这部分隐性开销也应计入总拥有成本，而非只看单机报价。

部署与规划里的常见坑

坑一是过度分区。把分区键设成高基数维度（用户 ID、设备、细到小时且租户极多），分区数爆炸，part 文件数失控，查询反而变慢。记住：分区是管理边界不是加速键，高基数维度放 ORDER BY 首位。

坑二是物化视图滥用。给所有维度都建物化视图，写入放大和存储膨胀反噬，写入吞吐下降、成本上升。正确做法是只前置高频、固定、与最常见分析窗口对齐的聚合，即席探索仍走明细表或轻量聚合。

坑三是内存不设上限。max_memory_usage 留 0（不限），平时没事，一旦几个大查询并发就把节点内存吃光，引发 OOM 或连锁失败。应当基于实测峰值设单查询上限，并配合服务端总内存与用户级聚合内存一起约束。

坑四是忽略 TTL 与生命周期。明细表无限增长，SSD 被历史数据占满，热卷水位触发频繁迁移，I/O 抖动。应当用 TTL 把冷数据定期下沉到 HDD/对象存储，并定期清理不再需要的分区。

坑五是集群规模盲目扩张。以为加节点就线性加能力，结果 Keeper 协调压力、跨分片通信、元数据管理成为新瓶颈。更现实的是按业务域拆多个逻辑集群，或对超大规模采用物化视图链预聚合降低查询扫描量。

坑六是拿 ES 的搜索心智来用 ClickHouse。把 ClickHouse 当全文检索引擎建表、做高基数的任意字段过滤，结果既不如 ES 灵活又浪费列存的压缩优势。两者定位不同，下文 FAQ 会专门区分。

数据规模到节点配置的映射参考

上表为规划参考区间，非实测结论。实际节点数、内存与并发能力高度依赖真实查询混合、数据压缩率与字段类型，落地前务必结合业务查询画像做压测，具体阈值以官方实时文档为准。

常见问题

什么业务适合用 ClickHouse？
适合 append-only 的高吞吐写入、以聚合分析为主的业务，比如用户行为分析、实时业务大盘、广告与业务报表、海量事件聚合。它的强项是"对几亿到千亿行做秒级聚合"，典型查询是按时段、维度做 COUNT、SUM、UV（uniq）等。如果你的核心诉求是频繁更新单行、强事务、复杂多表 join 的数据录入系统，或者需要任意字段全文检索，那 ClickHouse 不是合适的首要选择。判断是否上 CH，关键看"写多、聚合多、明细偶尔下钻"这三条是否同时成立。

分区键到底应该怎么设计？
官方结论是大多数表不需要分区键，需要时也通常不必细过分月，可观测性场景按天才常见。分区键应选"查询常用它做范围过滤、且基数适中"的维度，最常见是按事件时间 toYYYYMM 或 toDate。两条硬约束：分区总数别超过约一千，否则 part 文件和文件描述符过多反而拖慢查询；绝不用用户 ID、设备名等高基数字段做分区键，高基数维度应放进 ORDER BY 首位利用稀疏索引。多租户可审慎用（时间, 租户）元组分区，但要警惕租户数把分区撑爆。

物化视图在 ClickHouse 里起什么作用？
它是"写入时自动计算并落盘的独立聚合表"，由源表、AggregatingMergeTree 聚合表、以及连接二者的视图组成。写入明细时，视图按 GROUP BY（如按小时的 bucket、维度）算出聚合状态（uniqExactState、sumState 等）写入聚合表，查询时用 Merge 或 SELECT ... FINAL 取结果。作用是把聚合成本从"每次查询时重扫原始行"挪到"写入时一次算好"，让大盘查询只扫聚合后小几个数量级的数据，单位查询成本随原始数据量几乎不增长。它最适合写多读少、查询高度规律的报表场景。

并发上来后，内存和 CPU 怎么估算？
分三层：单查询并行度 max_threads 默认等于 CPU 核数，决定扫描并行与单查询 latency；单查询内存 max_memory_usage 必须按实测峰值设定并留余量，0 表示不限（危险）；服务端用 max_server_memory_usage（常见参考为物理内存 60%–80%）和 max_concurrent_queries 等准入控制兜底。反推公式：节点总内存 ≳ 单查询峰值内存 × 期望并发 × 安全系数；CPU 核数则在"max_threads=核数"与软线程上限（约 2×核数）之间按查询类型定。所有阈值需真实查询混合压测校准，以官方实时文档为准。

存储该选 SSD 还是 HDD？
按访问频率分层最划算：当期高频查询数据放 SSD（NVMe 更优），历史明细、合规留存、低频下钻下沉到 HDD 或对象存储。ClickHouse 通过存储策略自动搬运——热卷设 max_data_part_size_bytes，合并后变大的 part 自动进冷卷；或用 TTL 规则（如 90 天后 TO DISK 'hdd'）定时迁移。注意 HDD 上的 part 默认不合并，慢盘 I/O 要单独留余量。结论：不要全 SSD，也不要把 HDD 当便宜 SSD 用，按热数据比例决定 SSD 占比才是降本关键。

ClickHouse 和 Elasticsearch 到底有什么区别？
定位不同：ES 以倒排索引见长，强项是任意字段的全文检索、日志检索、模糊匹配与近实时搜索；ClickHouse 是列式 OLAP 引擎，强项是海量结构化数据的聚合分析与时序统计。用 ES 做"几亿行按维度 GROUP BY 出报表"往往成本高、聚合慢；用 ClickHouse 做"任意关键词全文检索"也不如 ES 灵活。两者可以互补：日志检索走 ES，行为数据的报表与大盘走 ClickHouse，而不是用其中一个硬扛两种诉求。具体能力边界以官方实时文档为准。

数据一致性怎么保证？
ClickHouse 是分析型引擎，不主打强事务 ACID，更常见的是"最终一致"模型：副本通过协调服务（Keeper/ZooKeeper）同步 part 元数据与复制队列，异步达成副本间一致；物化视图的聚合状态在合并时通过 *Merge 函数得到正确结果。对一致性要求高的写入，应关注写入幂等、使用原子替换分区（ALTER TABLE ... REPLACE PARTITION）等手段。若业务需要跨行强一致的事务语义，应在上游系统保证，再把结果以 append 方式导入 ClickHouse 分析，而不是依赖 CH 做事务源头。

集群后续怎么扩容？
横向扩容靠增加分片提升容量与并发上限，纵向扩容靠提升单节点内存/CPU/磁盘。新增分片后，已有分片的历史数据通常不会自动重新均衡，需要通过重导或调整分片权重把新数据路由过去；副本数增加则提升可用性与读吞吐。更稳妥的超大规模做法是按业务域拆成多个逻辑集群，减少单集群的协调与跨分片开销。扩容前后都要重新做查询画像压测，确认内存与并发参数仍匹配，避免"加了机器却没加吞吐"的情况。具体运维命令以官方实时文档为准。

结论：成本与配置如何条件化决策

回到开头的账单问题，结论可以条件化地给出：当你的业务以"写多、聚合多、明细偶尔下钻"为主，且热数据只占整体的一小部分时，ClickHouse 的单位查询成本和冷存储成本明显优于传统云数仓的打包计费；但当并发查询密集、单查询扫描宽、且表结构设计不到位时，它会在内存与节点数上把成本收回去。

具体决策遵循三条条件：其一，按查询并发与热数据比例决定 SSD 占比——热数据比例低就大头用 HDD/对象存储，只在热卷留足 SSD，不必全 SSD 阵列；其二，用物化视图把高频固定聚合前置，让大盘查询命中聚合表而非重扫明细，这是降本杠杆最大的一环；其三，分区键按"时间（+审慎的租户维度）"设计、把高基数维度放进 ORDER BY 首位，既保证分区数可控又能借助稀疏索引加速。节点规模则由"单查询峰值内存 × 期望并发 × 安全系数"反推，而非凭经验拍数。所有参数与版本差异请以 ClickHouse 官方实时文档为准，落地前用真实查询混合压测校准，才能把"省"稳定地落进月度账单里。

数据来源

ClickHouse 官方文档《Custom partitioning key / 自定义分区键》（clickhouse.com/docs）：分区键设计原则、PARTITION BY 表达式、分区数量与过度分区警示、ORDER BY 与分区的关系。

ClickHouse 官方指南《Build a rollup with materialized views for fast time-series analytics》（clickhouse.com/docs/guides）：物化视图 + AggregatingMergeTree 的 rollup 模式、AggregateFunction 状态（uniqExactState/sumState/countState）、SELECT ... FINAL 用法。

ClickHouse 官方资源《High-concurrency sizing for user-facing analytics》（clickhouse.com/resources）：max_threads、max_memory_usage、max_concurrent_queries、concurrent_threads_soft_limit_ratio_to_cores 等并发与资源控制项说明。

ClickHouse 官方文档《max_threads session settings》《storage_* server settings》（clickhouse.com/docs）：max_threads 默认值与内存压力下调机制、storage_policy/volume/disk、max_data_part_size_bytes、move_factor、TTL 迁移等分层存储配置。

第三方调优参考（Memory Tuning Guide 等社区文档）：max_server_memory_usage 取物理内存 60%–80%、单查询内存按比例设定等经验值，属社区调优建议，非官方承诺，具体以官方实时文档为准。