需要知道的前提
ClickHouse的query_result_cache只能缓存“已经执行完成”的结果。 也就是说它能缓存的是“第一个慢查询结束后，后面TTL时间内过来的同样的查询”，而不能解决“第一个慢查询还没结束，用户连续刷新”的并发打爆问题。
分析业务情况
从生产环境抓“高峰期1h”对应接口的SQL数据（理想情况）
- 查询次数
query_duration_ms的p99,p95,p90- 一个时间窗口内（30s、1min），“相同SQL”的重复次数
- 结果集的大小
- CPU负载和query时延的关系
具体情况
条件有限
- 没有Click House的 system.query_log权限
- 只有grafana面板的权限
- 可以下载完整时间段的query log overview，但是每次只能下载1min范围的对应POST接口日志
目标
在有限的条件中：
- 优化接口查询
- 为缓存设置合理的
TTL、use_query_cache_min_query_duration等参数 - 验证有效性
思路
只使用 Query overview 数据 （来自 someday） 来近似分析热点查询行为，并服务于两个目标：
- 找出当前高峰期的热点慢查询，明确优化重点。
- 估算
query_cache_ttl、use_query_cache_min_query_duration的第一版参数。
注意：
-
这里分析的是
normalized_query级别的重复窗口，不是“完全相同 SQL + 完全相同参数”的精确重复。 -
分析更适合作为首版参数依据，不是最终最优值证明。