一条 ClickHouse 报表查询从 3 秒变成 40 秒，你会从哪些指标和执行环节排查？
我的判断
报表从 3 秒变 40 秒，先对比扫描数据、分区裁剪、查询日志和 Part 状态，确认是数据增长、计划变化还是资源争抢。
我会在 system.query_log 对比快慢两次的 read_rows、read_bytes、内存、ProfileEvents 和等待时间，并拿到完整 SQL 与参数。扫描量突然扩大，先查时间条件是否还能分区裁剪、过滤是否匹配排序键、函数或类型转换是否让条件下推失效。
扫描量没明显变化但耗时暴涨，就看同时间并发、CPU、磁盘吞吐、远程读、merge/mutation 和内存超限后的外部排序。分布式查询还要拆到各分片，确认是不是一个慢分片或数据倾斜拖住整体。
修复可能是收紧时间范围、调整排序键、预聚合、改写 JOIN、限制返回列，或把高频维度做物化视图。改结构前会用生产数据影子表验证跳过比例和写入成本。
只看 SQL 文本很容易误判。ClickHouse 最有用的第一证据通常是“实际读了多少行和字节”。
容易答偏踩坑误区
- 用 FINAL 解决所有重复。 大范围 FINAL 会显著增加查询成本。
- SELECT * 再由应用丢列。 列式存储的优势被主动放弃。
- 只扩 CPU。 如果瓶颈是扫描错误、慢磁盘或单分片倾斜，扩容未必有效。