3.3 EXPLAIN精读：逐行读执行计划
3.3 EXPLAIN 精读：逐行读执行计划
本节摘要：EXPLAIN 是翻译官的交底文档。本节给出一份完整的多表查询执行计划，从上到下逐行注释：依赖区怎么看 Stage 关系、算子区怎么核对谓词与投影、统计区怎么读行数估算、路径区怎么确认分区裁剪；再用 EXPLAIN ANALYZE 的实际行数揭穿估算失真，最后给出一套固定的读计划检查清单。
样例查询与完整计划
用一条覆盖了"过滤、连接、聚合、排序"四类算子的查询做标本：
EXPLAIN SELECT c.region, COUNT(*) AS order_cnt, SUM(o.amount) AS total_amt FROM orders o JOIN customers c ON o.customer_id = c.customer_id WHERE o.dt = '2026-01-15' AND o.amount > 50 GROUP BY c.region ORDER BY total_amt DESC;
MR 引擎下的输出（Hive 3.x 典型格式，注释后加）：
STAGE DEPENDENCIES: -- 依赖区：先看有几段、谁等谁 Stage-1 is a root stage -- 主计算段：Join 加 GroupBy Stage-2 depends on stages: Stage-1 -- 排序段：等 Stage-1 出结果 Stage-0 depends on stages: Stage-2 -- 取数段：把结果送回客户端 STAGE PLANS: Stage: Stage-1 Map Reduce Alias -> Map Operator Tree: -- Map 端：按表别名分分支 o TableScan alias: o Statistics: Num rows: 1200 Data size: 96000 Filter Operator predicate: (amount > 50) (type: boolean) Select Operator expressions: customer_id (type: string), amount (type: decimal(10,2)) c TableScan alias: c Statistics: Num rows: 80 Data size: 8000 Select Operator expressions: customer_id (type: string), region (type: string) Reduce Operator Tree: Join Operator condition map: Inner Join 0 to 1 keys: customer_id (type: string) Group By Operator aggregations: count(), sum(amount) keys: region (type: string) mode: hash -- Map 端预聚合已被纳入本段 Path -> Alias: hdfs://nm/user/hive/warehouse/mydemo.db/orders/dt=2026-01-15 Path -> Partition: dt 2026-01-15 -- 路径区：分区裁剪的书面证据 Stage: Stage-2 Map Reduce Reduce Operator Tree: Group By Operator mode: mergepartial Select Operator expressions: region, count, sum File Output Operator compressed: true table: {name: default.query_result}
逐行读下来，这份文档能回答六个问题：扫了哪些表、过滤在哪端、连接键是什么、聚合分几段、排序占不占独立段、分区裁剪是否生效。下面按区拆解读法。
EXPLAIN 输出的解剖图
依赖区：先数段
STAGE DEPENDENCIES 列出段与依赖。样例三段：Stage-1 算主体、Stage-2 排序、Stage-0 取数。数段是估重量的最快动作——段数与 Shuffle 次数、落盘次数直接挂钩，三段以上的查询就该留意是否有可削减的环节（比如 ORDER BY 是否必要、能否用排序后的存储代替）。
Stage-0 通常是 FETCH 或把结果写临时表再回传，几乎无成本；真正要审查的是带 Map Reduce 字样的计算段。Tez 引擎下没有 Stage 编号，换成 Vertex dependency 一行（Map 1 <- Reducer 2），语义相同：顶点数对应段数。
算子区：核对翻译质量
算子区按"Alias 分支 + Reduce 汇合"组织。核对四件事：
谓词完整性。amount 大于 50 出现在 o 分支的 Filter 里，dt 条件不在谓词里是正常的——它进了路径区（下文）。如果你写的条件在算子区找不到对应 predicate，也不在路径区，就要警惕被优化器改写或丢弃（极少数版本兼容问题会出现谓词丢失，属于要报障的级别）。
投影列清单。o 分支的 Select 只剩两列，c 分支只剩两列。80 列的 orders 只搬运 2 列，说明列裁剪生效。SELECT 星号的查询这里会列出全部列，搬运体量一目了然。
连接键与连接类型。Join Operator 的 keys 与 condition map 声明内连接与键。多表连接时核对这个清单，能发现"以为按 A 键连、实际按 B 键连"的低级但致命的错误。
聚合模式。hash 与 mergepartial 成对出现即两段式聚合。样例里 hash 在 Stage-1 的 Reduce 树里（MR 模式下预聚合发生在 Reduce 任务的取数侧），mergepartial 在 Stage-2——不同引擎细节略有差异，判断标准始终是"成对出现"。
统计区与路径区：估算与事实
Statistics 行是优化器的"世界观"：Num rows 1200、Data size 96000。两个用途：一是判断扫描量级，二是与真实规模对照。如果表实际十亿行而统计区显示百万级（统计信息过期），CBO 的连接顺序决策就会建立在幻觉上——第 7 章 ANALYZE TABLE 语句专门刷新这些数字。
路径区回答"物理上打开哪些目录"。样例只列了 dt 等于 2026-01-15 的一个目录，分区裁剪实锤。核对裁剪看路径区，不看谓词——谓词写对了但函数包裹导致裁剪失效时，算子区一切正常，路径区却列出全部目录，红牌只有这里能抓住。
EXPLAIN ANALYZE：用事实校对估算
EXPLAIN 只给计划，ANALYZE 给计划加实测：
EXPLAIN ANALYZE SELECT c.region, COUNT(*) AS order_cnt FROM orders o JOIN customers c ON o.customer_id = c.customer_id WHERE o.dt = '2026-01-15' AND o.amount > 50 GROUP BY c.region;
输出里每个算子旁边多了实际行数与耗时，例如 Statistics: Num rows: 1200 之后跟着 actual rows 的数字。两两对照，三种典型案情：
- 估算百万、实际一万：统计信息过期或分区新增未统计，先 ANALYZE TABLE 再看 CBO 决策；
- 某 Reduce 顶点 actual rows 百倍于兄弟顶点：数据倾斜实锤，进入第 6 章的治理流程；
- Filter 后行数几乎没降：过滤条件选择性差（比如对性别列过滤），别指望它救性能。
注意 ANALYZE 会真执行查询，大表上先确认代价。日常节奏是：EXPLAIN 看结构（零成本、随时用），结构可疑再 ANALYZE 取证（有限成本、定点用）。
一份可背下来的检查清单
把本节内容压缩成每次提交前的六问：
- 段数（Stage 或 Vertex 个数）与查询的必要复杂度匹配吗？有没有可砍的 ORDER BY、可合并的子查询？
- 路径区只列了目标分区吗？分区列上有没有函数包裹？
- Filter 紧贴 TableScan 吗？谓词清单与 WHERE 条件一一对应吗？
- 投影列是不是只含必要列？星号改掉了吗？
- Join 键正确吗？小表有没有机会转 MapJoin（第 6 章的判读细节）？
- 统计行数与业务常识同一量级吗？差异大就先刷新统计。
六问过一遍通常不超过两分钟，却能拦下大半的"上线才暴雷"。从下一章起，每个新概念（分区、分桶、ORC、CBO）都会给出它在 EXPLAIN 里的指纹——检查清单会随着你的武器库一起加长。
本节要点回顾
- 四区读法：依赖区数段、算子区验翻译、统计区对估算、路径区验裁剪；
- 数段估重：段数对应 Shuffle 与落盘次数，是查询重量级的第一指标；
- 裁剪看路径区：谓词正常不代表裁剪生效，目录清单才是书面证据；
- 两段式聚合标志：mode hash 与 mergepartial 成对出现；
- ANALYZE 取证：估算与实际对照，抓统计过期与数据倾斜两类要案；
- 六问清单：段数、裁剪、下推、投影、连接键、估算量级，提交前过一遍。