Appearance
ClickHouse 查询性能常见坑：为什么语句不复杂却还是越跑越慢
ClickHouse 很容易给人一种错觉：
SQL 不复杂，列式库又很快，那查询应该天然就稳。
但真正到业务里，更常见的现象是：
- SQL 看起来很短
- 数据一上量就明显变慢
- 看板、明细、导出混在一起跑
- 集群 CPU 没打满，查询却越来越拖
先说结论
ClickHouse 查询慢，最常见的问题通常不是语句写错，而是：
- 表设计和查询模型不匹配
- 明细层承担了太多汇总职责
- 过滤维度和排序键不贴合
- 查询边界没收住
- 导入、merge 和查询在争抢资源
一、为什么“SQL 不复杂”不代表就会快
分析型系统和 OLTP 不一样。
很多 SQL 虽然语法简单，但背后可能会：
- 扫很多分区
- 读很多列
- 做大量聚合
所以真正要关心的是：
- 查询到底读了多少数据
- 分区裁剪和排序键是否命中
- 这条 SQL 是不是在用明细层硬扛报表需求
二、最常见的几个坑
1. 习惯性 select *
在分析型场景里，这通常比想象中更重。
2. 明细表直接承接所有报表
前期方便，后期最容易出问题。
如果一张明细表同时承担：
- 高并发看板
- 临时钻取
- 大范围导出
- 多维聚合
后面很容易彼此拖慢。
3. 分区和排序键设计只是“看起来合理”
真正关键的是：
- 是否真的贴合高频查询条件
比如业务最常按时间 + 租户 + 场景过滤，你却按另一个低频字段排序，查询自然很难快。
4. 业务方无限加筛选条件
最后会把一条原本稳定的查询链路拖成“万能查询器”。
三、还有两类经常被忽略的问题
1. 时间范围越放越大
前期默认看最近 1 天没问题，后面临时改成 30 天、90 天，扫描范围瞬间放大。
2. 后台 merge 和导入抢资源
很多查询慢不是单纯 SQL 问题，而是刚好撞上：
- 批量导入
- 大表 merge
- TTL 清理
- 物化视图写入
四、怎么把问题收回来
- 高频报表优先走汇总层或物化视图
- 查询入口限制最大时间窗口
- 表设计围绕真实过滤条件重做排序键
- 明细查询、看板查询、导出查询分层
- 高峰期尽量避免大批量导入和重 merge
总结
ClickHouse 变慢很多时候不是因为“它不够快”，而是因为查询模型已经超出了表设计的边界。只要把排序键、分区裁剪、分层建模和查询入口边界收好，大多数性能问题都会明显缓解。