列式查询性能数据的解读单线程扫描吞吐并不能代表并发分析场景的表现。复杂GROUP BY、GLOBAL JOIN和后台 merge 会改变内存、磁盘与尾延迟的分布。评估 ClickHouse 时应把 QPS、扫描量与内存峰值、parts 数、错误率和延迟分位数一起看。本文给出相应的检查方法。一、 ClickHouse 基准测试的三大指标陷阱ClickHouse 的列式存储与 SIMD 向量化指令使得它在单查询大规模连续 Scan 场景下表现卓越但这往往会掩盖生产环境中的并发瓶颈。陷阱 1被 OS PageCache 掩盖的物理 I/O 瓶颈在重复运行同一个基准测试 SQL 时后续运行的响应时间通常会大幅缩短。这是因为 Linux PageCache 已经将对应的 Column 文件加载到了内存中。若测试未在每轮测试前清理 Cache测出来的只是“内存读取速度”而非磁盘真实 I/O 性能。陷阱 2只看 Avg Latency忽略内存峰值Peak MemoryClickHouse 是典型的“空间换时间”引擎。在计算COUNT(DISTINCT user_id)或未优化的GROUP BY时内存占用随着基数呈线性甚至指数增长。平均耗时 200ms 的 SQL如果单次消耗 15GB 内存那么在 10 并发下就会直接挂掉整台服务器。陷阱 3忽视图数据 Part 碎片化Data Parts CountClickHouse 的写入性能依赖于 LSM-Tree 式的异步 Merge 机制。如果在压测期间仅测试纯查询而没有模拟后台持续INSERT带来的 Data Part 频繁 Merge测试结果将远好于实际生产环境。二、 正确的指标评估体系与统计口径评估 ClickHouse 性能需要将指标分为“效率指标”与“资源开销指标”两大类指标名称提取来源科学判定标准异常风险标志P99 / P999 Latencysystem.query_logP99 延迟不应高于 P50 的 4 倍P99 极高说明存在严重线程锁争抢或 GC 暂停Peak Memory Usagesystem.query_log.memory_usage单查询 Memory $ 10%$ 节点物理内存接近max_memory_usage阈值随时可能 OOMScan Efficiencyread_rowsvsresult_rows过滤比 $\frac{\text{read_rows}}{\text{result_rows}} 100$过滤比大于 $10000$说明 Primary Key 索引未生效Data Part Multipliersystem.parts单分区 Part 数量 $ 15$Part 数量超过 100报Too many parts in partition告警三、 方案对比三种不同场景下的 ClickHouse 性能模式查询场景类别典型 SQL 模式瓶颈点核心观察指标优化方向海量日志 ScanSELECT count() FROM logs WHERE ...CPU 向量化计算与磁盘 BPSRead MB/s, CPU 向量化使用率建立 Skip Index、调整 Block Size高基数聚合SELECT user_id, count() GROUP BY user_id内存 Hash Table 大小Memory Peak Bytes使用two_levelGROUP BY 或物化视图多表 Complex JoinA LEFT JOIN B ON A.id B.id内存构建 Hash JoinJoin Memory, Network Interconnect改为 Single Table 宽表设计或 Distributed Join四、 生产级性能数据分析与系统表提取脚本以下 Python 脚本能够自动连接 ClickHouse 节点抓取最近指定时间段内的压测日志system.query_log并计算出真实的 P50/P90/P99 耗时分布、内存消耗峰值与扫描效率。import sys import json import logging import numpy as np from typing import Dict, List, Any import clickhouse_connect logging.basicConfig(levellogging.INFO, format%(asctime)s - %(levelname)s - %(message)s) class ClickHousePerformanceAnalyzer: def __init__(self, host: str 127.0.0.1, port: int 8123, user: str default, password: str ): self.client clickhouse_connect.get_client(hosthost, portport, usernameuser, passwordpassword) def analyze_benchmark_session(self, query_tag_prefix: str, last_minutes: int 15) - Dict[str, Any]: 从 system.query_log 中分析包含指定 tag 的基准测试 SQL 表现 sql f SELECT query_id, query_duration_ms, memory_usage, read_rows, read_bytes, result_rows, exception_code FROM system.query_log WHERE type QueryFinish AND event_time now() - INTERVAL {last_minutes} MINUTE AND query LIKE %{query_tag_prefix}% ORDER BY event_time DESC try: res self.client.query(sql) rows res.result_rows if not rows: logging.warning(No benchmark logs found matching criteria.) return {} durations [r[1] for r in rows] memories_mb [r[2] / (1024 * 1024) for r in rows] read_rows [r[3] for r in rows] read_bytes_mb [r[4] / (1024 * 1024) for r in rows] # 统计计算 Percentiles report { total_executed_queries: len(rows), latency_ms: { p50: round(float(np.percentile(durations, 50)), 2), p90: round(float(np.percentile(durations, 90)), 2), p99: round(float(np.percentile(durations, 99)), 2), max: round(float(np.max(durations)), 2), }, memory_usage_mb: { p50: round(float(np.percentile(memories_mb, 50)), 2), p99: round(float(np.percentile(memories_mb, 99)), 2), peak_max: round(float(np.max(memories_mb)), 2), }, scan_performance: { avg_read_rows_per_query: int(np.mean(read_rows)), avg_read_mb_per_query: round(float(np.mean(read_bytes_mb)), 2), total_scanned_gb: round(float(np.sum(read_bytes_mb) / 1024.0), 2) } } return report except Exception as ex: logging.error(fFailed to fetch system.query_log analysis: {str(ex)}) return {error: str(ex)} if __name__ __main__: # 使用示例分析带 SQL 标记 -- BENCHMARK_RUN_01 的性能日志 analyzer ClickHousePerformanceAnalyzer(host127.0.0.1, port8123) # 模拟数据输出 print(--- Fetching ClickHouse System.Query_Log Benchmark Report ---) report analyzer.analyze_benchmark_session(query_tag_prefixBENCHMARK_RUN, last_minutes30) print(json.dumps(report, indent2))五、 如何根据性能数据指导生产调优拿到上述真实性能数据后应当按照以下决策树执行优化若 Peak Memory 过高 节点内存 30%检查 SQL 中是否有大表的GLOBAL JOIN尝试将其重构为普通JOIN或开启max_bytes_before_external_group_by允许溢出写盘。若 P99 Latency 远大于 P50且 Read Rows 巨大说明 Primary Key 定义不合理扫描了大量无关的 Data Part。重新检查ORDER BY索引列顺序将高频过滤字段前置。若并发升高时出现Too many parts报错调整写入端 Batch 策略确保单次INSERT包含至少 10,000 行以上数据降低 ClickHouse 后台 Merge 压力。把 query log、内存峰值和 parts 状态放在同一时间窗口分析才能区分 SQL 问题、写入节奏和资源竞争。