1. 为什么要做 ClickHouse 性能测试，测之前先想清楚这几件事
在真正把 ClickHouse 用到线上之前，或者在做 ClickHouse 数据库整体迁移的时候，有一件事怎么都绕不过去——性能测试与评估。这不是跑几个 SQL 看看快不快就完事的，而是要用一套可重复、可比较、能暴露问题的方法，把系统的真实能力摸清楚。
很多人对 ClickHouse 的第一印象是“查得快”，这个印象没错，但“快”是有前提条件的。它快在宽表聚合、快在列式扫描、快在按主键过滤的区间查询，但在高并发小查询、频繁点查、极端数据倾斜、大面积数据更新这类场景下，ClickHouse 的表现远没有宣传的那么完美。如果没测过就直接上线，等到线上出现慢查询、资源被打满、查询互相拖垮的时候，再来排查代价就高了。
所以这篇内容适合谁看？适合正在评估 ClickHouse 能不能接住你的业务、准备做迁移前评估、或者已经在用但想搞清楚系统瓶颈在哪的工程师。我不会讲太多官网文档里能查到的东西，重点放在“我实际是怎么测的”“测完怎么看数据”“哪些参数帮你解决问题”这几块，都是能直接落地参考的。
1.1 性能测试不是跑几个 SQL 就完事
先纠正一个常见的误区：性能测试不等于功能测试。功能测试关心的是“查询结果对不对”，性能测试关心的是“在多长时间内、用多少资源、在多高并发下，结果能出来”。这两个目标经常是冲突的，比如同一条 SQL，不同执行计划走出来的耗时可能差很多，但结果完全一致。所以做性能测试时，我们要控制变量，保证每次查询走的是同一条路径，测试结果才有可比性。
ClickHouse 性能测试至少涉及三个层面：单查询性能、并发查询性能和写入性能。单查询性能衡量的是这条 SQL 在这个数据集上的极限耗时，回答“最坏情况下要等多久”；并发查询性能回答的是“同时 50 个人点报表，会不会把 CPU 打满或者互相拖垮”；写入性能回答的是“每秒能接住多少条数据，批量写和实时写分别什么表现”。
另一个容易忽略的点是：ClickHouse 的查询性能高度依赖数据分布。同样的 SQL，在数据均匀分布的表上可能毫秒级返回，在数据倾斜严重的表上可能几十秒都跑不完。测试数据必须尽可能接近真实业务的数据特征，否则测出来的数字没有参考价值。
1.2 测试目标决定一切：先定义“什么算性能好”
我见过不少团队做性能测试，上来就问“ClickHouse 是不是比 MySQL 快 100 倍”，这种问法本身就没法回答。性能测试的第一步不是选工具，而是定义“好”的标准。
拿一个实际场景举例：假设我们要评估 ClickHouse 能否支撑一个用户行为分析平台，核心需求是每天接入 10 亿条埋点数据，分析师在 BI 工具里做条件筛选和聚合查询，P95 响应时间需要控制在 3 秒以内。这个目标定下来之后，整个测试方案就有了方向：数据集规模应该按 30 天到 90 天的数据量来造，查询要覆盖日期范围过滤、多维 group by、去重计数、时间窗口聚合这些典型模式，并发数要按团队规模设到 20 到 50 个并发查询，最后看 P95 能不能压进 3 秒。
反过来，如果只是做一个几百台服务器日志查询的内部工具，并发要求只有 5 个以内，那测试重点就应该放在单查询性能和写入吞吐上，并发压测做到 10 个并发基本就够了。测试标准不是越严越好，而是贴近真实负载才算有效。
所以在正式动手前，建议先花半天时间把下面这张表填清楚：核心查询场景是什么、表数据量多大、数据增长速率多快、每日查询量级多少、并发峰值多少、延迟要求多少、可用性要求多少。这张表填完，测试方案基本就成型了。
2. 环境与数据准备：测试结果靠不靠谱，一半看这里
ClickHouse 性能测试有个特点：硬件稍微变一变，结果能差出一个数量级。磁盘从 HDD 换成 NVMe SSD，查询耗时可能直接下降 60% 以上；CPU 主频高一点，复杂聚合的耗时差别也很明显。所以环境准备阶段的目标不是“跑出最好看的数字”，而是“跑出可复现、可对比的数字”。
环境搭建这块，我先给一个参考配置，再解释为什么这么搭。我这次测试用了 3 个节点的 ClickHouse 集群，每台机器是 16 核 CPU、64GB 内存、2TB NVMe SSD，操作系统是 CentOS 7.9，ClickHouse 版本用的 24.3 LTS。三台机器组成一个 cluster，副本数设为 2，数据分布在两个分片上。这套配置不算豪华，但已经能代表大多数中小规模生产集群的真实水平，测出来的数据有实际参考意义。
2.1 测试环境怎么搭，才能让数据“说真话”
第一个建议：测试环境一定要独立。别为了省事把 ClickHouse 装在正在跑业务的机器上，也别和 Kafka、Redis 这些服务混部。原因很简单，ClickHouse 压测会把 CPU 和磁盘 IO 打到很高，如果旁边还跑着别的服务，CPU 争抢会直接污染测试数据。另外 ClickHouse 的内存管理策略比较激进，默认会尽量多吃内存，混部的话很容易把同机其他进程挤到 OOM。
第二个建议：操作系统层的参数不要动太多，但有几个必须设置。文件句柄数限制（ulimit -n）要调大，官方推荐至少 1048576，否则高并发压测时会报 "Too many open files"；禁用透明大页（THP），因为 THP 在内存分配时可能造成较大的延迟抖动，对延迟敏感的查询影响很明显；CPU 调频策略设成 performance，避免 CPU 频率动态变化导致测试结果不稳定。这几个参数设置完，再用 sysbench 或者简单的 CPU 跑分工具做一次基线测试，确认三台机器性能一致。
第三个建议：ClickHouse 的版本要尽早锁定。每个版本的查询优化器、聚合算法、MergeTree 合并策略都可能不一样，测试中途换版本是大忌。如果是为了迁移做评估，那就用目标生产环境的同版本；如果是新项目选型，就用最新的稳定版（LTS 优先），测完记录下来，后续升级时还能做对比。还有一个隐蔽的坑：不同版本对 SQL 的解析行为有差异，比如某些函数支持了新的参数，同一句 SQL 在新版里的执行计划可能完全变了，这会让跨版本对比失去意义。
2.2 造数据：测试集设计比你想的重要得多
数据集的设计是整个测试里最容易被低估的环节。数据太规整，测出来的性能偏乐观，上线后真实数据一进来，性能直接崩；数据太乱，又分不清慢是慢在数据还是慢在 SQL。合理的做法是尽量模拟真实数据，并且把极端情况也放进去。
以我这次的用户行为分析场景为例，我造了一张行为日志表，包含用户 ID、事件类型、事件时间、页面 URL、设备类型、地域、停留时长等字段，总行数 1 亿行，时间跨度 90 天。数据特征上做了这么几件事：用户 ID 的基数按 1000 万设计，保证 group by 是真正的高基数聚合；事件类型里埋了一个热点事件，占比 30%，模拟真实业务里的头部效应；地域字段按二八分布，少数几个地域占了大部分数据；事件时间做了每天 24 小时不均衡分布，白天数据量明显高于凌晨。
造数可以用 Python 脚本生成 CSV 再导进去，也可以用 ClickHouse 自带的generateRandom函数直接生成。generateRandom用起来简单，但生成的数据是完全均匀的随机分布，和真实业务差距较大，建议还是自定义一个脚本，用随机权重来控制分布。造数脚本本身不复杂，但有个效率问题：1 亿行数据如果一条条 INSERT 会非常慢，正确做法是先用 Python 按批量生成文件，然后用clickhouse-client --query="INSERT INTO table FORMAT CSV" < data.csv导入。我实测 1 亿行数据大概 30GB，单节点批量导入约 15 分钟能完成，三节点集群加副本会慢一些。
数据造完之后，不要急着开测，要先做一轮数据质量校验：COUNT 总数是否等于预期、关键字段的值分布是否符合预期、各分片数据量是否均衡。数据倾斜在 ClickHouse 里不是小问题，如果某个分片上的数据明显多于其他分片，查询会把那个节点打满，整体性能会被拖垮。我见过有人在测试时发现节点间数据量差了 3 倍，查了半天才发现是分片键选错了，这种问题越早发现代价越小。
3. 查询与写入性能测试：从单条 SQL 到并发压测的完整执行记录
环境准备好、数据造完之后，就进入真正的测试环节。整个测试过程我分成三条线：先做单查询性能基线，再做并发压测，最后补上写入性能测试。顺序上之所以先查后写，是因为查询性能是最核心的指标，先把查询能力摸清楚，再考虑数据能不能喂得进来。
3.1 单查询性能基线：用 clickhouse-benchmark 跑一轮
单查询测试有两种常用方式：一种是用官方的clickhouse-benchmark工具，另一种是自己写脚本循环执行查询取平均值。我的习惯是两种都用，但以官方工具为主，原因是它输出了完整的统计信息，包括 min、max、mean、quantile 等，省得自己写统计逻辑。
clickhouse-benchmark的基础用法很简单：
clickhouse-benchmark --query "SELECT count() FROM events WHERE event_date >= '2024-01-01' AND event_date < '2024-02-01'" --host 127.0.0.1 --port 9000 --iterations 100 --concurrency 1这条命令会对指定查询跑 100 次，并发设为 1，输出每次查询耗时、平均值、中位数、P95、P99 等指标。我建议每次跑之前先清空缓存，否则第二次跑命中了 page cache，数据全在内存里，耗时会是冷查询的十分之一不到，完全没有参考价值。清缓存的方法是先执行SYSTEM DROP FILESYSTEM CACHE（需要管理员权限），或者用clickhouse-client执行SYSTEM DROP MARK CACHE和SYSTEM DROP UNCOMPRESSED CACHE。
单查询测试的 SQL 集是根据真实业务场景整理的，一般 20 到 30 条，覆盖这几类：
- 简单条件过滤，比如
SELECT count() FROM events WHERE event_date = today()，模拟报表请求。 - 多条件组合过滤，比如时间范围加设备类型加地域，模拟分析师的筛选操作。
- GROUP BY 聚合查询，比如按天、按设备类型统计 PV/UV。
- 多表 JOIN 查询，模拟维度表关联。
- 排序加 LIMIT 的分页查询。
- 包含去重逻辑的 UV 类查询，
uniqExact和uniqCombined都要测，因为两者的性能差异很大。
测试结果整理成一张表，每一条 SQL 对应一行，记录 min、avg、P95、P99 四个值。这张表就是后面所有调优工作的基线，没有它，你根本不知道改动到底起没起作用。
3.2 写入性能测试：批量导入与实时写入都要测
ClickHouse 的写入性能测试经常被忽略，但它恰恰是最容易出现“上线后才发现数据进不来”事故的环节。写入测试要从两条路径分别测：批量导入和实时写入。
批量导入对应的是离线场景，比如每天凌晨从离线数仓同步数据。测试方式很简单，用之前准备好的数据文件反复导入多张表，观察导入耗时、每秒行数、每分钟数据量等指标。批量导入的性能瓶颈主要在磁盘 IO 和 MergeTree 的合并速度上。这里有个细节值得注意：导入速度不等于写入速度，因为 ClickHouse 的写入是先落内存再异步合并，写进去的数据最初是 part 文件，后台再慢慢 merge 成大文件。如果批量导入太快，后台合并跟不上，会导致 part 数量暴涨，查询性能大幅下降。测试时除了看导入耗时，还要观察system.parts表里的 part 数量变化，如果 part 数持续增长不下降，说明合并能力已经到瓶颈了。
实时写入对应的是流式接入场景，比如从 Kafka 消费埋点数据写入 ClickHouse。测试方式是用一个小脚本模拟多线程写入，每条数据单条插入，观察写入延迟和吞吐量。ClickHouse 官方对实时写入的建议是“攒批”，不要一条条写，推荐每次插入至少 1000 行或者等待 1 秒再 flush。这是因为每条 INSERT 都是一次独立的写操作，会产生一个 part 文件，写入过于频繁会导致 part 文件爆炸。实测单条插入吞吐大概在每秒几千行的量级，而攒批 1000 行写入可以轻松到每秒几十万行。
写入测试要特别注意数据可靠性验证。写完之后立刻查询 COUNT 是否等于写入行数，这个步骤不能省。ClickHouse 在异常情况下的写入失败不一定报错，尤其在使用异步写入时，可能会静默丢数据。我建议在写入测试结束后，用系统的CHECK TABLE命令检查数据完整性，再用不同时间窗口的 COUNT 和 SUM 做交叉验证。
3.3 并发场景：用 JMeter 做 SQL 压测的正确姿势
并发压测是评估 ClickHouse 生产能力的核心环节。很多人以为并发压测就是起几十个线程同时查询，把请求打过去看响应时间，其实没那么简单。并发压测的核心是找到系统的“拐点”：并发数从 10 涨到 100 的过程中，吞吐量是线性增长还是很快触顶？延迟是平稳上升还是突然恶化？这个拐点决定了系统的容量上限。
JMeter 是常用的压测工具，方案可以这么设计：用 JDBC Connection Configuration 配置 ClickHouse 的 JDBC 驱动连接，用 Thread Group 控制并发线程数，用 JDBC Request 执行查询 SQL，用聚合报告和事务控制器统计结果。具体步骤：
- 下载 clickhouse-jdbc 驱动，放入 JMeter 的 lib 目录。
- 添加 JDBC Connection Configuration，配置数据库 URL（格式如
jdbc:clickhouse://127.0.0.1:8123/default）、用户名、密码，空闲连接数设大一些，比如 50，防止连接成为瓶颈。 - 添加线程组，并发数从 10、30、50、100 逐级递增，每个线程组循环执行多次查询。
- 添加 JDBC Request，写入要压测的 SQL。一条 SQL 对应一个 JDBC Request 比较好，如果用 Variable Name 动态传参，要确保参数化逻辑正确。
- 添加监听器，重点看 Aggregate Report 里的 Average、95% Line、Throughput 指标。
这里有一个很多人踩过的坑：JMeter 默认的 JDBC 连接池参数如果不调，压测时会出现连接获取超时，导致大量请求失败。解决方案是把 JDBC Connection Configuration 里的 Max Number of Connections 设为线程数的 2 倍以上，Connection Timeout 设成 10000 毫秒。
并发压测的执行策略也很有讲究。不要一上来就把并发拉到 100，要逐级加压：先 10 并发跑 3 分钟，再 30 并发跑 3 分钟，然后 50、100、200，每个并发级别跑完先看吞吐量和延迟数据再继续。如果中途出现查询失败或延迟暴涨，说明已经到了系统瓶颈，不必强行压上去。
还值得一提的是，现在有不少团队开始用 AI 辅助生成压测脚本，比如让 AI 根据业务 SQL 自动生成 JMeter 脚本模板。这个做法能省不少时间，但脚本里参数化、断言、连接池配置这些逻辑，AI 生成的版本往往不够精细。我的建议是：AI 写的脚本只能当草稿，必须人工 Review 一遍连接配置和线程参数，最好用一条已知性能基线 SQL 跑一遍校准，确认压测结果和数据一致再用于正式测试。
4. 结果分析与调优：从测试数据里挖出系统的真实瓶颈
测试跑完只是第一步，真正有价值的工作在分析阶段。很多人测完拿到一堆数据不知道怎么解读，或者看到 P95 不准就想调参，结果越调越乱。这里分享一套我总结的分析思路：先看现象，再定位瓶颈，最后才动手调优。
4.1 先看指标，再谈优化：响应时间、吞吐量、资源使用率怎么解读
拿到压测报告，第一件事是看整体趋势，而不是纠结某一两个慢查询。先回答下面几个问题：
吞吐量（QPS）是随并发数线性增长，还是到了某个并发数就停滞了？如果停滞，停滞在哪个并发级别？响应时间（P95）是从一开始就随并发上升，还是到一个阈值后突然恶化？资源使用率里，CPU 是全部打满还是部分核心忙、部分核心闲？内存使用率有没有异常增长？磁盘 IO 的等待时间是否明显偏高？
把这几个问题看清楚，基本就能判断系统瓶颈在哪个环节。我举几个常见的案例：
- CPU 打满但吞吐量不涨，说明 CPU 是瓶颈。这时候再调高并发只会让延迟增加，应该考虑加节点、优化 SQL、减少计算量。
- CPU 使用率不高但响应时间很高，说明系统可能在等锁或者等磁盘 IO。先看磁盘 IO 等待时间，再看是不是出现了大量内存溢出、数据落盘。
- 内存持续上涨且触顶，可能是查询过于复杂导致中间结果集过大，触发了内存上限和磁盘回写。ClickHouse 的日志里会明确记录这种事件。
举个例子，我之前测一张 10 亿行的日志表，执行按用户 ID 去重计数的查询，单并发耗时 1.8 秒。看起来不算慢，但把并发提高到 30 之后，P95 直接恶化到 8.5 秒，吞吐量反而低于 20 并发的水平。排查发现是内存不足导致部分聚合操作触发了磁盘临时数据落盘，ClickHouse 的 group by 聚合在内存放不下时会 spill 到磁盘，这个过程会急剧拖慢查询。解决办法是调整max_bytes_before_external_group_by参数，让它在内存用到一定程度时就提前启用外部聚合，避免内存打满才触发导致性能雪崩。
4.2 常见的调优方向：MergeTree 家族、索引、分区与参数
分析完瓶颈之后，调优才有方向。ClickHouse 的调优维度很多，我重点说四个我实践下来收益最大的方向。
第一个是表引擎选择。同样是 MergeTree 家族，不同引擎的特长完全不同。如果数据有明确的业务时间维度，用MergeTree配合时间分区；如果业务是“只追加不改历史”，可以用Log或TinyLog类型，查询更轻量；如果数据量极大且经常要按主键点查，可以考虑ReplacingMergeTree或AggregatingMergeTree做预聚合。表引擎选错，后续不管怎么调参都是隔靴搔痒。
第二个是 ORDER BY 键和主键索引设计。这是我见过最多人犯错的地方。ORDER BY 决定了 ClickHouse 稀疏索引的排布方式，直接影响查询的过滤效率。基本原则是：高频过滤条件的列放在前面，区分度高的列放在前面。比如一个用户行为表，业务查询经常按event_date加user_id过滤，那 ORDER BY 里的顺序应该是event_date, user_id，而不是反过来。如果 ORDER BY 把高基数列放太靠前，前缀匹配会很快失去过滤效果，导致扫描大量无关数据。
第三个是分区设计。分区粒度不是越细越好，分区太细会产生大量小文件，合并压力大，查询时也要扫描多个分区；分区太粗则过滤效果差。一般按天或按周分区比较合适，如果历史数据需要长时间保留，可以按 TTL 自动过期，避免手动删除分区带来的性能波动。我建议用EXPLAIN语句检查查询覆盖的分区数，如果一个查询扫了 90 个分区但实际只需要最近 7 天的数据，说明查询条件没有走分区裁剪，这时要检查查询条件是否用上了分区键，或者分区键设置是否合理。
第四个是查询参数调优。有几组参数对查询性能影响很大：max_threads控制每个查询使用的 CPU 线程数，默认是 CPU 核数，但对小查询来说线程太多反而会增加调度开销，可以调到 8 到 16；max_memory_usage控制单个查询的最大内存使用，防止大查询把整机内存吃光；max_bytes_before_external_group_by控制 group by 时是否启用外部聚合，建议在内存的 60% 左右设置；max_concurrent_queries控制同时执行的查询数，超过这个数的查询会排队等待，对控制系统的稳定性很重要。
调优是一个反复循环的过程：调整参数或表结构，重新跑同样的 SQL 集，对比基线数据，如果不改善就回滚。不要凭感觉一次改好几个参数，那样出了问题完全无法定位。我习惯一次只改一个变量，记录前后数据差异，形成一个小的调优日志，时间久了这就是宝贵的数据库优化经验库。
5. 测试过程中踩过的坑与排查实录
写这篇文章的时候，我把这些年做 ClickHouse 性能测试遇到的高频问题整理成了一份排查速查表。这些问题看似零散，但都真实影响过测试结果的准确性，分享出来能帮你避开不少冤枉路。
5.1 内存超限导致查询直接 OOM
这是我遇到最多的问题。ClickHouse 默认配置下，一个复杂的 GROUP BY 查询可以把内存吃到十几个 GB，如果并发查询一多，机器直接 OOM。第一次遇到我还以为是 ClickHouse 的 bug，后来才发现是参数没有调好。
解决方案分三个层次：
- 先用
max_memory_usage把单查询内存限制住，比如设成 16GB。超限后查询会因为内存不足报错，但至少不会拖垮整个节点。 - 如果业务允许，用
max_bytes_before_external_group_by让 ClickHouse 在内存接近上限时就启用外部聚合，把中间结果写到磁盘。实测这个参数可以把内存压力降低 50% 以上，代价是查询时间从秒级变成十几秒，但比 OOM 强多了。 - 最后的兜底方案是给 ClickHouse 进程配置 cgroup 或者 systemd 的内存限制，避免进程无节制地吃内存，把操作系统拖死。不过这个属于运维手段，最好还是从查询和参数层面解决。
顺便提醒一下：ClickHouse 的 OOM 并不总是立刻报错，有时候表现出来的是查询突然变慢。因为操作系统内存不足时，会先做 swap 或者触发 page cache 回收，磁盘 IO 飙升，查询性能全面恶化。所以压测时遇到“没报错但性能明显下降”的情况，优先看一下dmesg里有没有 OOM 记录，以及系统的内存水位。
5.2 并发测试线程数上不去，连接数被卡死
JMeter 压测时，经常遇到并发数提到 50 以上就开始出现大量连接超时报错。最开始我以为是 ClickHouse 服务端的问题，查了半天system.metrics里的当前连接数，发现远没到上限，后来才定位到是 JMeter 的 JDBC 连接池配置有问题。
点击 JMeter 里的 JDBC Connection Configuration，里面有个 Max Number of Connections 参数，默认值通常比较小，如果并发线程数大于这个值，线程就会排队等连接，超时后报错。解决方法是把最大连接数设成并发线程数的 2 到 3 倍，同时把 Connection Timeout 设长一些，比如 10000 毫秒。
ClickHouse 服务端的连接数限制也要注意，默认的max_connections一般不用调，但如果压测机和服务端之间有负载均衡或者代理，连接数会被代理层限制住，这时候排查链路可能花不少时间。我有个经验技巧：压测时用watch -n 1 "clickhouse-client --query='SELECT count() FROM system.metrics WHERE metric LIKE \"TCPConnection%\";'"实时观察连接数变化，如果卡在某个值上不去，基本就是链路中间层的问题。
5.3 结果波动大？可能是系统层面在捣乱
性能测试最怕的就是“测试结果不可复现”。同样的 SQL，第一次跑 P95 是 2 秒，第二次变成 4 秒，第三次又回到 2.5 秒，这种波动会让所有分析失去意义。
引起波动的原因通常是这几个：
- page cache 没有清理。第一次查询之后，数据已经加载到系统内存的 page cache 里，第二次查会快很多。解决方法是查询之间清理缓存，或者冷热数据交替测试。
- 后台合并进程（MergeTree 的 merge）在跑。如果表里正在发生大规模的 part 合并，磁盘 IO 和 CPU 都会被占掉，查询性能自然下降。测试前最好先执行
SYSTEM STOP MERGES暂停合并，测完再恢复。 - CPU 频率动态调整。服务器设置了省电模式的话，CPU 频率会在负载变化时波动。测试前确认 BIOS 或系统层面设成 performance 模式。
- 其他进程抢占资源。这个前面说过，压测机器不能混部其他服务。
还有一个比较容易忽略的因素：ClickHouse 的查询日志。如果压测过程中有大量system.query_log写入，也会占用资源。建议测试完再整理日志，而不是测试过程中让日志实时写入。
5.4 测试数据落差大，可能是数据分布没模拟好
这个坑我提过一次，但值得再强调：如果真实业务的数据分布和测试数据差距过大，那么测试结果基本没有参考价值。一个比较典型的场景是时间字段的数据分布。真实业务的数据往往有很强的周期性，比如白天是晚上的好几倍，但测试数据如果均匀分布在每天，那按天分区的查询性能测试结果就会偏乐观。实际跑的时候，白天时间段的数据量更大，扫描的分区大小不均，查询性能反而不如均匀分布时理想。
另外还要注意 NULL 值和空字符串的处理。ClickHouse 对有空值的列在存储和计算上都有自己的内部实现，如果真实数据里有大量空值，测试数据里也要按比例加入，否则字段的压缩率和索引选择都会和真实情况有偏差。
结尾
做一轮完整的 ClickHouse 性能测试，工作量比想象中大。最花时间的不是跑测试本身，而是数据准备和结果分析。数据造得越贴近真实，测试结果越有价值；指标看懂了，才知道瓶颈在 CPU、内存还是磁盘上。
我个人在实际操作中最深的体会是：性能测试不要只做一次。系统的负载特征会随业务发展而变化，数据量从 1 亿涨到 10 亿，SQL 逻辑越来越复杂，ClickHouse 的性能表现也会完全不同。建议至少每季度做一次基准回归测试，把当时记录的性能基线数据翻出来对比，这样能及早发现性能劣化的趋势，而不是等用户投诉了才想起来排查。
最后再分享一个小技巧：测试完成后，把 ClickHouse 的system.query_log和system.part_log里的关键信息导出备份，这些日志保留了实际查询的执行计划、扫描行数、耗时统计等数据，比你自己记录的测试结果要精确得多。后续调优时翻出这些日志做二次分析，经常能发现当初没注意到的问题。
