ClickHouse POC 怎么测把写入、Merge、冷热缓存都带上ClickHouse 单条查询很快只说明那次缓存与数据分布下很快。POC 要带上持续写入、后台 Merge、租户竞争和冷热数据否则最高 QPS 没多少选型价值。基准先写清楚边界压测报告至少应包含 ClickHouse 版本、表结构、排序键、数据量与分布、并发模型、写入模式、机器规格以及缓存是冷还是热。把查询分成典型路径小范围过滤、聚合、宽表扫描和向量检索。不要用单个“最高 QPS”代表整体能力。配置没有脱离场景的最优值index_granularity、跳数索引和向量索引都会交换写入、存储和查询成本。更细的粒度可能减少部分过滤扫描也会增加索引体积索引是否有效取决于过滤条件与数据分布。调整前后都应对同一批 SQL 做回归并关注system.parts、system.merges与内存使用。关注点应比较的内容排序键过滤条件与读取范围是否匹配批量写入Parts 增长、Merge 排队和端到端延迟跳数索引跳过率、索引大小与写入开销向量检索召回目标、过滤组合、内存预算一个最小测试循环SELECT query_kind, quantile(0.95)(query_duration_ms) AS p95_ms, count() AS samples FROM system.query_log WHERE event_time now() - INTERVAL 30 MINUTE AND type QueryFinish GROUP BY query_kind;这类统计应与测试窗口内的写入速率和 Merge 状态一起看。出现回归时先确认数据、缓存和并发是否可比再修改参数。压测脚本的意义是让其他人能复现条件而不是得出一个看起来漂亮的数字。
