GBase 8a 慢 SQL 排查实战：MPP 执行路径与定位方法

线上 GBase 8a 集群里，业务侧说的「一条 SQL 很慢」，在 DBA 眼里往往要拆成：算得慢、等得慢、传得慢 三类。8a 是 MPP 架构：协调节点（Coordinator）负责解析与下发计划，数据节点（Data Node）并行执行扫描与关联，节点之间还要做 Motion（典型算子如 REDISTRIBUTE、BROADCAST）。因此同样一条 SELECT，在单机库可能只盯索引；在 8a 上还要问：有没有跨节点洗牌？分布键是否对齐？统计信息是否骗优化器？是否某个分片拖尾？

本文给一套可落地的排查顺序，并附一个「Join 键与分布键不一致导致 REDISTRIBUTE」的简化案例，便于对照 EXPLAIN 阅读。

一、先分类：别把所有「慢」都当成 SQL 写得差

接到慢查询后，建议先记 排查四元组：完整 SQL、开始时间、涉及表及量级、是否首次执行。然后按下面分支走，避免一上来 CREATE INDEX：

现象	优先怀疑	建议动作
仅第一次慢，第二次明显变快	冷读、计划编译、缓存未热	连跑两次对比；看是否仍需优化
每次执行都慢	计划差、分布键差、统计信息旧	EXPLAIN + 查表 DDL 分布键
集群忙时全都慢	IO/网络/内存、锁、单节点异常	先看监控与长事务，再看单 SQL
只有某张分片节点 CPU 飙高	数据倾斜、本地大排序	查倾斜键、重分布后的单节点聚合

在 gccli 里可先确认会话上下文，避免把锁等待当成算力瓶颈：

-- 当前库、会话（示例，以现场版本为准）
SELECT DATABASE();
SHOW PROCESSLIST;

若 SHOW PROCESSLIST 里状态长期是 Locked 或等待某表，先处理事务与锁，再谈 EXPLAIN。

二、用 EXPLAIN 读懂 8a 计划在「传什么」

EXPLAIN 展示的是逻辑计划，重点不是「有没有走索引」一句话，而是数据在节点间如何流动：

• REDISTRIBUTE：按 Join 键或 GROUP 键把行重新哈希到各节点，网络与序列化开销大，数据量大时常常是头号杀手。
• BROADCAST（或类似广播算子）：小表广播到所有节点，适合极小维表；维表变大时广播会拖垮网络。
• 本地扫描 + 本地 Hash Join：关联键与两侧分布键一致时，才可能做到数据不动、本地完成 Join。

示例 SQL（事实表 orders 按 user_id 分布，维表 users 较小但未复制）：

EXPLAIN
SELECT o.user_id, SUM(o.amt)
FROM orders o
JOIN users u ON o.user_id = u.id
WHERE o.dt = DATE '2026-05-01'
GROUP BY o.user_id;

阅读计划时建议用笔标出：

1. orders 扫描后是否紧跟 REDISTRIBUTE？若 Join 键 user_id 本就是 orders 的分布键，却仍重分布，要查统计信息或是否触发了子查询改写。
2. users 是 BROADCAST 还是也被 REDISTRIBUTE？维表行数上万仍广播就要警惕。
3. GROUP BY o.user_id 能否 本地聚合（分布键 = user_id 时通常更优）？

若计划里出现 NestLoop + 大表驱动，且统计信息很久未收集，先做一次 ANALYZE 再对比计划，比盲目改 SQL 更有效。

-- 收集统计信息（表名、语法以环境文档为准）
ANALYZE TABLE orders;
ANALYZE TABLE users;

三、分布键设计：Join 性能的第一道关

8a 事实表常见 HASH 分布。核心原则：高频 Join 键尽量与分布键一致，让优化器少做 REDISTRIBUTE。

建表示例（概念演示）：

CREATE TABLE orders (
  order_id   BIGINT,
  user_id    INT,
  dt         DATE,
  amt        DECIMAL(18,2)
)
DISTRIBUTED BY ('user_id');  -- 分布键与常用 Join/Group 键对齐

实践里常踩的坑：

1. 按日期分布、按用户 Join：DISTRIBUTED BY (dt) 却 JOIN ON user_id，几乎必洗牌。
2. 倾斜键做分布键：如按「省份」分布，某省数据占 80%，会出现单节点热点，慢在「某一个 DN」而不是平均慢。
3. 大维表既不复制又不分布对齐：反复 REDISTRIBUTE 维表侧数据。

处理倾斜的思路：换分布列（更均匀的键）、业务上拆热点省份、或用中间表预聚合后再 Join。索引解决不了跨节点洗牌；索引只能帮助单节点扫描更快，Motion 代价仍在。

四、案例：一条「看起来简单」的聚合为何要到 40 秒

场景：orders 约 8 亿行，按 user_id HASH 分布；users 约 500 万行，默认随机分布。业务 SQL 按天过滤后 Join 再 GROUP BY user_id，执行 40s+。

EXPLAIN 摘要（文字描述）：

• orders：分区裁剪后仍扫描千万级 → REDISTRIBUTE on user_id
• users：全表扫描 → REDISTRIBUTE on id
• 之后 Hash Join + 跨节点 Gather 汇总

根因：两侧都要重分布才能对齐 Join 键；网络与 CPU 双重放大。

改法（择一或组合）：

1. 将 users 改为 复制表（若版本与容量允许），消除一侧 REDISTRIBUTE。
2. 若 users 必须 HASH，则按 id 分布，与 orders.user_id 对齐。
3. 先按天把 orders 聚合到临时表（分布键仍为 user_id），再 Join 维表，减少 Join 行数。

改后再跑 EXPLAIN，目标计划应出现：一侧本地扫描、一侧广播或小表 REDISTRIBUTE、Join 前不再双侧大洗牌。同类问题在 8a 现场非常常见，值得单独沉淀为团队案例库。

五、资源与节点级：当计划「看起来没问题」仍然慢

若 EXPLAIN 已较合理，仍偶发变慢，继续查：

• 各数据节点 CPU/IO 是否均衡：某 DN 长期顶满，可能是倾斜或本地大排序（ORDER BY 非分布键）。
• 网络带宽与交换机：REDISTRIBUTE 高峰时打满千兆/万兆，表现为「集群整体慢」。
• 长事务与锁链：未提交的大事务阻塞元数据或行锁，PROCESSLIST 可见。

此时应优先 限流、错峰调度大 SQL、扩容 DN 或网络，而不是继续堆索引。

六、推荐排查清单（可打印对照）

[1] 记录 SQL、时间、表量级、是否首次执行
[2] gccli：是否有锁等待 / 长事务
[3] EXPLAIN：标出 REDISTRIBUTE、BROADCAST、Gather、Join 顺序
[4] 查 DDL：分布键、复制表、分区键是否与 WHERE/JOIN 匹配
[5] 统计信息：大表加载后是否 ANALYZE，对比前后计划
[6] 仍慢：看 DN 级监控是否倾斜、网络是否打满
[7] 落地改法：对齐分布键 > 复制小维表 > 改写 SQL/中间表 > 再考虑索引

小结

GBase 8a 慢 SQL 排查的核心，是承认 MPP 的代价在「数据怎么在节点间移动」。EXPLAIN 盯 Motion 算子，DDL 盯分布键与倾斜，监控盯单 DN 拖尾，比单纯「加索引」更贴近根因。建议把每次优化的 前后计划对比、分布键变更、耗时 记入案例，后续同类问题可直接复用判断路径。