我先给结论，再说明它在项目里解决什么问题。ClickHouse 擅长扫描和聚合海量列式数据。优化重点不是让每条语句都“走索引”，而是尽量少读分区、少读数据块、少读列，并减少高基数聚合和不必要的数据交换。

核心机制我会按一次真实执行过程来讲。沿着「解析 SQL 与谓词 → 分区/主键/跳数索引裁剪 → 并行读取所需列 → 执行聚合连接排序 → 输出结果并记录 querylog」观察输入、状态与输出，这些阶段都可以从日志、指标或源码里验证。 解析 SQL 与谓词 查询优化从读取量开始：PREWHERE 可先读过滤列，再读取命中行的其他列。 分区/主键/跳数索引裁剪 分区和主键裁剪依赖条件能映射到表定义，函数包装和弱相关排序会扩大扫描。

实现细节只抓关键入口，不会整段背源码。system.querylog：readrows、memoryusage、ProfileEvents。 EXPLAIN PIPELINE：并行执行管线。 我会先确认请求实际走到了哪条路径，再用运行数据验证，不会只看类名或配置猜测。

放到生产使用时，我会关注参数和验证数据。固定数据快照对比 PREWHERE、投影和预聚合，混合并发下验证。 固定输入和基线 先在没有故障注入的环境执行上述配置，固定数据规模、并发度、运行时版本和预热时间。以「readrows/resultrows」为主基线，记录值应满足「记录稳态基线」；同时保存 readrows/readbytes、resultrows 比例，使后续变化能够回到同一时间轴比较。

最后补充常见误区和使用边界。WHERE 对 eventtime 使用 toDate 函数且表按原时间排序，无法形成有效范围。改写为半开时间区间，并让租户列位于 ORDER BY 前缀后，读取行数下降几个数量级。 只调 maxthreads 掩盖扫描过大：readrows/readbytes：先减少扫描列和行。 SELECT 读取无关列：resultrows 比例：限制高基数聚合。 方案：更适合的场景：主要收益：代价与边界。 改写查询利用排序键：过滤条件与主键相关：无需额外存储、收益直接：受现有表布局限制。 物化视图预聚合：固定聚合高频重复：查询读取极少：写放大与回填一致性。 新建投影/宽表：多种稳定访问路径：优化器可选择更合适布局：存储与维护成本增加。 选型至少带上 日增量、分区规模、查询并发、扫描行数和压缩比，并用上面的量化基线验证；未知数据应明确为待测假设。