ClickHouse 性能测试完整实操指南3步跑通 TPC-H横评 PostgreSQL/MySQL 实测数据说话【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse同一张约 10 亿行的表全表聚合查询MySQL 量级在 30s 上下PostgreSQL 约 20~30sClickHouse 实测能压到 1s 以内。这就是这篇文章要带你做的事——不背概念直接用 clickhouse-benchmark 和 tests/benchmarks/ 里的 TPC-H、TPC-DS 套件把 ClickHouse 性能测试跑起来再和 PostgreSQL、MySQL 做一轮变量可控的基准测试对比最后给出 4 个当天见效的调优动作。全文约 3000 字跟着做即可复现。你的查询到底慢在哪query_log 和 explain 是前两道拿到一个慢查询先别动配置先回答一个问题时间是花在算、还是花在等 I/O第一步查system.query_log一条 SQL 定位慢查询看elapsed_us、result_rows、read_rows三个字段读了几亿行只吐出一行结果多半是谓词没下推或者排序键白建了read_rows很小但依然慢去查网络和副本。SELECT query_id, elapsed_us, read_rows, read_bytes, query FROM system.query_log WHERE event_date today() AND type QueryFinish ORDER BY elapsed_us DESC LIMIT 10;第二步看执行计划和逐节点耗时EXPLAIN PIPELINE看线程调度EXPLAIN PLAN看谓词下推SYSTEM PROFILE EVENTS或system.processors_profile_events看每个算子实际跑的时间。定位到瓶颈后才轮到基准测试出场——用 clickhouse-benchmark 用法 把这个查询在新旧配置下各跑 100 次变成可复现的数字而不是靠感觉判断好像快了。3 步跑通 TPC-H 22 条查询指标怎么看才不踩坑tests/benchmarks/ 下每个套件都是自包含的以tpc-h/为例目录里只有三样东西init.sql建表语句、settings.json跑查询时强制的会话参数比如join_use_nulls 1保证各数据库在同一套语义下比、queries/22 条标准查询逐条编号命名。tpc-ds/结构相同只是查询集换成 99 条更复杂的数据仓库场景。三步跑完clickhouse-client --query DROP DATABASE IF EXISTS tpc_h; CREATE DATABASE tpc_h; ATTACH DATABASE tpc_h clickhouse-client --database tpc_h --multiquery tests/benchmarks/tpc-h/init.sql clickhouse-benchmark --query SELECT ... --iterations 100实际上 init.sql 之外还需要灌数据官方用 dbgen 或 ClickHouse 的 TPC-H 数据生成器仓库内 CI 脚本有现成流程灌完 22 条查询逐条执行即可。两个已知坑直接说Q6 原始写法在 ClickHouse 上有 Decimal 精度问题tpc-h/README.md 里给了带类型转换的替代写法Q11 的 FRACTION 参数要按 scale factor 调整。跑完别只看平均延迟这是新手最常犯的错。100 次执行里平均 0.8s、P99 却是 3s说明有冷缓存、后台 merge 或内存换页在捣乱这个平均 0.8s写进报告就是事故。正确的读法P50代表常态体验用来做横向对比的主指标P99 / P99.9代表最坏路径用来判断稳定性P99 超过 P50 两倍以上先查是不是混进了首轮冷查询对比前先跑 5~10 轮预热丢弃让页缓存和标记数据热起来clickhouse-benchmark的--time、--iterations参数就是干这个的它自带 QPS、RPS 统计把每条查询的分布跑出来比单条手动计时可靠得多。横向对比方法论先控制变量再看 PostgreSQL / MySQL 各输在哪拿三台机器随便跑一轮出来的数字一文不值。ClickHouse vs PostgreSQL 性能对比要可信四个变量必须锁死硬件同机型、同核数建议 16 核起步、SSD、内存至少 64GB三库装在同规格环境至少保证对比时只改数据库不换机器数据量用同一份生成脚本灌数比如 10 亿行事实表 维度表记录好导入后的行数核对一致并发数从单连接跑起再逐步加到 16、32 并发画出并发-延迟曲线而不是只报单线程一个点预热轮次每轮正式测量前跑 5 次丢弃消除冷缓存差异测试数据怎么准备是这套方法论里最容易偷懒的环节。原则是贴近生产分布时间戳按业务节奏分布而不是全落在今天字符串列保留真实的基数特征ID 用乱序还是有序要说明白。拿不到生产数据时优先用公开的真实数据集灌进去测——下面这种现成样本库就比自己rand()出来的数据更有代表性在 10 亿行、16 核、NVMe 的环境量级下三类查询的胜负手大致是查询场景PostgreSQLClickHouse优势倍数全表聚合GROUP BY sum/avg20~30s0.5~2s10x~50x中等 JOIN1000 万行两表8~15s2~5s约 3x主键点查单行返回毫秒级10~50msPostgreSQL 胜结论别照抄数字抄结构聚合查询是 ClickHouse 的主场——列式存储让扫描只读需要的列向量化执行让每列一次处理一批这是 ClickHouse 列式存储 优势 的底层来源JOIN 场景 ClickHouse 赢但赢法不同它更鼓励你宽表化/预聚合把 JOIN 消掉而不是靠哈希 JOIN 硬扛大表关联点查是行存的主场ClickHouse 的单点查询要付列式读取的固定开销真要低延迟点查要么用 ReplacingMergeTree 小表 索引要么承认这种负载不适合放进来。从慢到快4 个调优动作按收益从大到小排① 排序键PRIMARY KEY设计——收益最大因为它决定了扫描量。MergeTree 的 ORDER BY 是主键索引也是分区内物理排序把查询里最常用的过滤前缀放前面ORDER BY (event_time, user_id)能直接砍掉几个数量级的读取行。这一步没做好后面全白搭。② 分区策略——按时间PARTITION BY toYYYYMM(t)让旧数据整分区跳过。但别分区太碎月分区通常够用按天分区会让小文件和小 part 泛滥。③ 二级索引选型——minmax 还是 bloom_filter规则一句话数值、日期、UUID 这类有序列用minmax跳过整个 granule 的 min/max 判断高基数等值过滤的字符串列用bloom_filter它只为等值和 IN 服务范围查询帮不上忙。一行建索引ALTER TABLE logs ADD INDEX idx_user user_id TYPE bloom_filter GRANULARITY 4;④ 压缩 Codec 与 join_algorithm——高基数字符串列默认 LZ4 换ZSTD(3)通常能省 30% 存储且查询侧解压开销可接受低基数字符串列套LowCardinality或DeltaZSTD。JOIN 侧把join_algorithm从 default 改成parallel多表大 JOIN 在多核上通常能再快 30%~100%小表灌进GRACE_HASH/HASH的内存上限也要注意溢盘了性能会断崖。顺序很重要先动 ①②数据模型再动 ③④查询参数反过来做大概率白干。把性能回归挡在合码前query_log CI 冒烟基准线上侧靠system.query_log建一条每日慢查询巡检elapsed_us超过基线 3 倍的 query 拉出来人工过一遍比盯 dashboard 有效。真正值钱的是把基准测试推进 CI。ClickHouse 自己的做法可以直接抄tests/performance/ 下每个.xml就是一个自包含的性能用例——create_query建表、fill_query灌数、query是要计时的基准查询跑在两台机器上master 参考版本 vs 你的分支输出是带统计显著性检验的对比报告性能回退会直接在 PR 上标红。你不需要搭这么重的系统最小可行版本是挑 5~10 条覆盖聚合/JOIN/点查的真实查询写成冒烟基准每次合码前在固定规格的机器上跑一轮单连接 16 并发各一组只比 P50 和 P99 相对基线的变化超过 10% 就挂数据准备、预热轮次、参数全部固化进脚本谁也别手动改性能测试不是发布前的一次性动作而是把慢查询变成可复现、可对比、可拦截的工程问题。想继续深入按这个顺序看tests/performance/README.md性能测试怎么写、怎么跑、tests/benchmarks/README.mdTPC-H/TPC-DS 套件结构、docs/en/operations/utilities/clickhouse-benchmark.mdbenchmark 工具全参数。跑一轮自己的数字比读十篇对比文有用。【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考