EXPLAIN 如何分析 ClickHouse 查询计划

做的事：真实对同一条查询跑4种EXPLAIN

代码EXPLAIN SYNTAX SELECT sum(v) FROM demo.threadtest WHERE k > 100 GROUP BY k % 10; EXPLAIN PLAN SELECT sum(v) FROM demo.threadtest WHERE k > 100 GROUP BY k % 10; EXPLAIN PIPELINE SELECT sum(v) FROM demo.threadtest WHERE k > 100 GROUP BY k % 10; EXPLAIN ESTIMATE SELECT sum(v) FROM demo.threadtest WHERE k > 100;

验证：四种模式，真实看到的是四个完全不同的层次

实测 · 本机执行输出

EXPLAIN SYNTAX（语法层：运算符被重写成函数调用）
→ SELECT sum(v) FROM demo.threadtest WHERE greater(k, 100) GROUP BY modulo(k, 10)

EXPLAIN PLAN（逻辑计划：抽象的执行步骤）
→ Aggregating
     Keys: k MOD 10 | Aggregates: sum(v)
  └──ReadFromMergeTree (demo.threadtest)
        Parts: 2 | Granules: 245

EXPLAIN PIPELINE（物理管线：真实的并行度细节）
→ (Expression) ExpressionTransform × 10
    (Aggregating) AggregatingTransform × 10
      (Expression) ExpressionTransform × 10
        (ReadFromMergeTree) MergeTreeSelect(...) × 10

EXPLAIN ESTIMATE（预估：不真正执行，只给数量级）
→ demo  threadtest  2(parts)  2000000(rows)  245(marks)

四条EXPLAIN真实对应四个由浅到深的层次：SYNTAX只做语法层面的重写，还没有涉及任何执行细节；PLAN给出的是逻辑上"要做哪几步"，但不涉及并行度这类物理执行细节；PIPELINE真实展开成了物理执行图，×10精确对应本系列前面《max_threads》验证过的本机10核并行度；ESTIMATE真实完全不执行查询本身，只是快速给出一个"大概要碰多少数据"的数量级预估。

真实的用法：不同问题，用不同层次的EXPLAIN

这四个层次真实对应排查不同类型问题时该看的地方：如果怀疑SQL被自动优化器改写成了意料之外的样子（比如本系列《ClickHouse聚合为什么快》验证过的count()真实会被优化成trivial count），SYNTAX能真实看到最原始的重写结果；如果想知道一条查询真实走了哪些索引/裁剪（本系列前面《分区裁剪》《Data Skipping Index》几篇大量用到的EXPLAIN indexes=1其实是EXPLAIN PLAN模式下的一个附加开关），PLAN层次最合适；如果怀疑某条查询没有真实用满预期的并行度，或者想确认Distributed查询真实在哪一层做汇总（本系列《分布式查询的两阶段聚合》验证过的MergingAggregated正是从PIPELINE/PLAN层面观察到的），PIPELINE能看到最贴近真实执行的细节；而ESTIMATE真实的价值在于它不用等查询跑完就能快速告诉你"这条查询大概要碰多少数据"，特别适合在真正执行一条可能很重的查询之前，先用它快速摸个底，避免真的跑起来才发现规模超出预期。本文验证过的这四种模式，加上此前多篇文章里穿插用到的actions=1这类附加参数，真实构成了排查ClickHouse查询行为时，从"SQL写了什么"到"底层真实做了什么"的完整工具链。

分步演示：从语法重写到物理管线再到数量级预估

每一步都是本文上面用真实4种EXPLAIN模式跑出来的原始结果。

四种EXPLAIN，真实四个不同深度的观察层次

这一步新验证的模式

本文用到的工具

本机 ClickHouse 26.9.4（单节点），真实对比 EXPLAIN SYNTAX/PLAN/PIPELINE/ESTIMATE

下一篇 · CLICKHOUSE 内部原理 85

system.query_log：一条查询到底耗在哪里