Appearance
ClickHouse 看板慢查询优化案例：日报接口为什么越查越慢
ClickHouse 很适合做分析型查询，但这不等于：
- 任何 SQL 扔进去都会一直快
很多团队第一次用它做看板，会经历一个阶段：
- 前期很快
- 数据一多就开始抖
- 看板接口越查越慢
场景
有一个经营看板接口，需要按天统计：
- 订单量
- GMV
- 支付转化
- 多维度筛选
前期直接查明细表没问题，后面数据规模上来后，日报接口耗时从几百毫秒涨到数秒。
先说结论
这类问题最常见的根因通常不是 ClickHouse 本身不够快，而是：
- 明细层承担了太多报表职责
- 排序键和过滤维度不贴合
- 需要预聚合的查询还在临时现算
所以优化重点一般是：
- 先区分明细查询和报表查询
- 再补汇总层或物化视图
- 最后收敛查询模型
一、先别急着调参数
看板查询变慢时，先判断三件事：
- 查的是明细还是汇总
- 过滤条件是否稳定
- 结果是不是高频重复被查询
如果是固定口径、频繁访问的日报和看板，长期直接扫明细表通常不是最优解。
二、为什么前期快，后期慢
因为前期数据量小，很多问题被掩盖了。
随着数据增长，下面几件事会越来越明显：
- 读取数据量变大
- 聚合维度变多
- 扫描范围开始失控
如果还在实时对明细表做复杂聚合，看板接口就很容易被拖慢。
三、一个更实用的排查顺序
第一步：先看查询到底扫了多少数据
最关键的问题不是 SQL 写得长不长，而是：
- 读了多少分区
- 扫了多少行
- 聚合时用了多少内存
第二步：看过滤条件是否命中表设计
如果表的排序键和业务高频过滤维度偏差很大，就会出现：
- 明明只查一小段业务数据
- 实际却扫了很大范围
第三步：看是不是把报表查询硬压在明细层
这点特别常见。
如果日报、周报、经营看板每次都现算，那数据量上来后抖动很正常。
四、这类问题怎么优化更稳
1. 明细层和汇总层分开
明细层适合：
- 留存原始数据
- 支撑追查和明细分析
汇总层更适合：
- 固定口径报表
- 高频看板接口
2. 用物化视图或预聚合减轻现算压力
如果业务口径相对稳定，这往往是收益最大的优化手段。
3. 收敛看板的查询模型
有些看板会不断加筛选条件，最后变成：
- 既想实时
- 又想任意维度组合
- 还想始终低延迟
这种需求要尽早和业务方对齐边界。
4. 生命周期管理也要跟上
老数据不一定还需要和热数据放在同一层去服务实时查询。
合理的分层和 TTL 能减轻长期负担。
五、一个典型优化过程
比如最开始接口每次直接查明细表：
- 扫近 30 天原始订单数据
- 做多个维度聚合
- 再返回日报指标
后面可以逐步改成：
- 明细表继续保留原始数据
- 增加按天汇总的物化视图
- 看板接口默认走汇总层
- 只有钻取场景才查明细
这类调整通常会比单纯改一版 SQL 更稳。
六、最容易踩的坑
1. 看到慢就先扩机器
如果查询模型和表设计不匹配，扩机器只能延后问题。
2. 所有分析口径都走一张超宽明细表
这会让系统后期维护成本越来越高。
3. 报表和排查共用同一条查询链路
报表追求稳定低延迟，排查更追求灵活性，这两类需求最好不要长期混在一起。
一句话总结
ClickHouse 看板查询变慢时，最重要的不是先调参数，而是先分清：
- 这是明细查询
- 还是汇总查询
把明细层、汇总层和看板查询边界拆开后，性能通常会稳定很多。