活动专区

活动公告

上车！GBase 8a开发者联盟发车了 技术福利、人脉资源全都有！

认证培训专区

认证培训资料

GBase 8s GDCA 认证培训课前准备

GBase 8a

其他

物化视图报错：references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them

01-GBase 8s 事务型数据库 安装与卸载

GBase 8s

适配迁移

[GBase 8s 教程]GBase 8s 常用函数、表达式

## 前言

在 GBase 8a MPP 集群上，多表 Join 是最常见的性能瓶颈来源之一。与单机数据库不同，MPP 环境下的 Join 需要考虑数据分布：若两表的 Join 键与各自的分布键不一致，优化器必须在执行 Join 前先移动数据——这一过程直接决定了查询是否产生大量跨节点传输。

本文面向 DBA 和 SQL 开发，梳理 GBase 8a 中三种主要 Join 数据移动策略（Local Join、Broadcast、Redistribute）的触发条件与 EXPLAIN 识别方法，并给出常见慢查询场景的排查步骤。前提知识：已了解 GBase 8a 的 Coordinator/DataNode 架构和 EXPLAIN 基本输出格式。

---

## GBase 8a Join 的三种数据移动策略

在 MPP 数据库中，Join 的前提是：两表中要 Join 的行必须出现在同一个 DataNode 上。若不满足这一条件，优化器会选择以下三种策略之一来「对齐」数据。

### 1. Local Join（本地 Join）

**触发条件**：两表的 Join 键与各自的分布键完全一致，分布方式均为 HASH 分布且分布列相同。

此时，同一 Join 键对应的行已经落在同一 DataNode 上，无需任何数据移动，直接在本地执行 Hash Join。这是性能最优的情形，也是建表时分布键选型的首要目标。

**EXPLAIN 特征**：Extra 无 BROADCAST 或 REDISTRIBUTE 标记；整个 Join 阶段在一个 Stage 内完成，不产生跨节点流量。

### 2. Broadcast（广播小表）

**触发条件**：两表大小差异显著，优化器判断将小表完整复制（Broadcast）到每个 DataNode 的代价，低于重分布大表的代价。

小表被广播到所有 DataNode，每个 DataNode 在本地与大表的对应分片做 Join。广播代价 = 小表行数 × (DataNode 数量 - 1)，适合小表（通常行数小于数万行，或数据量小于数十 MB）。

**EXPLAIN 特征**：Extra 中出现 `broadcast` 关键字，或小表端 type 为 ALL 且无 REDISTRIBUTE 标记。当统计信息准确时，优化器能正确识别小表并选择 Broadcast。

### 3. Redistribute（重分布）

**触发条件**：两表均不满足 Local Join 条件，且至少一张表行数过大不适合广播，优化器选择按 Join 键重新分布其中一张表（有时两张都重分布）。

Redistribute 的代价与参与行数和网络带宽正相关。在亿级大表场景下，一次 Redistribute 可能占整个查询耗时的 70% 以上，是最需要重点控制的数据移动类型。

**EXPLAIN 特征**：Extra 出现 `REDISTRIBUTE by ` 标记，其中 `` 为 Join 键列。

---

## 用 EXPLAIN 识别 Join 策略

以下示例将 `orders`（按 `user_id` 分布）与 `products`（按 `product_id` 分布）做 Join：

```sql
EXPLAIN
SELECT o.order_id, p.product_name, o.amount
FROM orders o
JOIN products p ON o.product_id = p.product_id
WHERE o.order_date = '2024-01-15';
```

**场景一：`products` 为小表，触发 Broadcast**

```
| id | select_type | table    | type | rows   | Extra     |
|----|-------------|----------|------|--------|-----------|
|  1 | SIMPLE      | p        | ALL  | 1200   | broadcast |
|  1 | SIMPLE      | o        | ref  | 85000  | Using where |
```

Extra 的 `broadcast` 表示 `products` 被广播到所有节点，`orders` 在各节点本地与之 Join。

**场景二：两表均大，触发 Redistribute**

```
| id | select_type | table    | type | rows    | Extra                      |
|----|-------------|----------|------|---------|----------------------------|
|  1 | SIMPLE      | o        | ALL  | 5000000 | REDISTRIBUTE by product_id |
|  1 | SIMPLE      | p        | ALL  | 800000  | Using where                |
```

Extra 中 `REDISTRIBUTE by product_id` 表示 `orders` 在 Join 前被按 `product_id` 重新分布，代价取决于 `orders` 的数据量。

**场景三：分布键与 Join 键一致，Local Join**

若将 `orders` 改为按 `product_id` 分布，同一查询的 EXPLAIN 中 Extra 不含 BROADCAST 或 REDISTRIBUTE，两表本地直接 Hash Join，为最优路径。

---

## 常见 Join 慢查询场景与排查步骤

### 场景一：大表与大表 Join 触发 Redistribute

**现象**：EXPLAIN 显示 `REDISTRIBUTE by `，行数估算在百万以上；查询运行时间数分钟甚至超时。

**排查步骤**：

1. 确认两表的分布键：

```sql
SHOW CREATE TABLE orders\G
SHOW CREATE TABLE products\G
```

找到各自的 `DISTRIBUTE BY HASH(...)` 列。

2. 比对 Join 键：若 `orders` 按 `user_id` 分布、`products` 按 `product_id` 分布，而 Join 条件为 `o.product_id = p.product_id`，则必然触发 Redistribute。
3. 评估优化方案（三选一）：
   
   - 若该 Join 是高频核心查询，将 `orders` 的分布键改为 `product_id`（需重建表并重新导入）
   - 若 `products` 行数较少（&lt; 10 万），将其改为复制表（REPLICATED），消除所有 Broadcast 和 Redistribute
   - 若无法修改表结构，用 CTE 先过滤再 Join，减少参与 Redistribute 的行数
4. 变更前后对比 EXPLAIN，确认策略切换是否生效。

### 场景二：小表未触发 Broadcast，转为 Redistribute

**现象**：明明是小表，EXPLAIN 中却出现 `REDISTRIBUTE`，而非预期的 `broadcast`；根因通常是统计信息过期，优化器高估了小表的行数。

**排查步骤**：

1. 执行 `SELECT COUNT(*) FROM ` 与 EXPLAIN 中的 `rows` 对比
2. 若差距超过 5 倍，执行 `ANALYZE TABLE ` 更新统计信息
3. 重新执行 EXPLAIN，确认是否切换为 Broadcast 策略

### 场景三：多表 Join 顺序不优

GBase 8a 优化器根据统计信息决定 Join 顺序（小结果集先驱动大表）。若统计信息过期，可能选择行数估算偏差大的驱动顺序，导致中间结果集膨胀，进而引发多次 Redistribute 或内存落盘。

```sql
EXPLAIN
SELECT a.col1, b.col2, c.col3
FROM t_large a
JOIN t_medium b ON a.id = b.a_id
JOIN t_small  c ON b.id = c.b_id;
```

逐一检查各表的 `rows` 估算是否与实际 `COUNT(*)` 结果量级相符。若 `t_small` 被高估为行数最多的表并排在最后 Join，应先对 `t_small` 执行 `ANALYZE`，再重新检查计划。

---

## Join 优化实践

### 分布键与 Join 键对齐

若某对表频繁做等值 Join，将两张表的分布键统一设为相同的 Join 键，可从根本上消除数据移动：

```sql
-- 两表均按 department_id 分布，Join 无需 REDISTRIBUTE
CREATE TABLE employee_records (
  emp_id        INT NOT NULL,
  department_id INT NOT NULL,
  hire_date     DATE,
  salary        DECIMAL(12,2)
) DISTRIBUTE BY HASH(department_id);

CREATE TABLE department_budget (
  department_id INT NOT NULL,
  budget_year   INT NOT NULL,
  budget_amount DECIMAL(18,2)
) DISTRIBUTE BY HASH(department_id);
```

建表时确定好核心 Join 关系，分布键的选择比事后 SQL 改写的收益更大。

### 用复制表消除 Broadcast 开销

对于行数少（&lt; 10 万行）但被频繁 Join 的维度表，设为 REPLICATED 后每个 DataNode 持有完整副本，所有 Join 均在本地完成，不产生任何 Broadcast 或 Redistribute：

```sql
CREATE TABLE dim_product (
  product_id   INT NOT NULL,
  product_name VARCHAR(128),
  category_id  INT,
  PRIMARY KEY (product_id)
) ENGINE=VORDERLY_REPLICATED;
```

后续所有以 `product_id` 为 Join 条件的查询，EXPLAIN 中不再出现 BROADCAST 或 REDISTRIBUTE。需注意：REPLICATED 表的写入操作（INSERT/UPDATE/DELETE）会同步到所有节点，适合更新频率低的维度表。

### 用 CTE 先过滤再 Join

当多表 Join 中间结果集大且含多处 REDISTRIBUTE 时，用 CTE 显式控制执行顺序，在 CTE 内先过滤再 Join，可有效减少参与数据移动的行数：

```sql
WITH filtered_orders AS (
  SELECT user_id, product_id, amount
  FROM orders
  WHERE order_date BETWEEN '2024-01-01' AND '2024-03-31'
    AND status = 'COMPLETED'
),
product_info AS (
  SELECT product_id, category_id, product_name
  FROM dim_product
  WHERE category_id IN (10, 20, 30)
)
SELECT f.user_id, p.product_name, SUM(f.amount) AS total
FROM filtered_orders f
JOIN product_info p ON f.product_id = p.product_id
GROUP BY f.user_id, p.product_name;
```

先通过 WHERE 条件缩减行数，再执行 Join，Redistribute 的数据量随之下降。

---

## 统计信息对 Join 计划的影响

Join 策略（Broadcast vs Redistribute）和 Join 顺序，完全依赖优化器的行数估算。统计信息缺失或过期会导致以下问题：

| 问题 | 现象 | 处理 |
|------|------|------|
| 小表行数被高估 | 本应 Broadcast 改为 Redistribute，代价增加 | `ANALYZE TABLE ` |
| 大表行数被低估 | 内存不足、落盘，或 Join 顺序选错 | `ANALYZE TABLE ` |
| 新加载数据后统计未更新 | EXPLAIN rows 与实际行数差距大 | 每次大批量加载后执行 ANALYZE |

定期在业务低峰期执行 ANALYZE，维持统计信息时效性：

```sql
ANALYZE TABLE orders;
ANALYZE TABLE products;
ANALYZE TABLE employee_records;
ANALYZE TABLE department_budget;
```

ANALYZE 完成后，重新执行 EXPLAIN 确认 `rows` 估算是否与 `SELECT COUNT(*)` 结果量级相符，再判断 Join 策略是否已调整为预期路径。

---

## 小结与检查清单

遇到多表 Join 性能问题时，按以下顺序排查：

1. **EXPLAIN 看 Join 策略**：Extra 无 REDISTRIBUTE/BROADCAST 为最优（Local Join）；出现 `REDISTRIBUTE by ` 需重点分析分布键是否对齐
2. **确认分布键**：`SHOW CREATE TABLE` 找 `DISTRIBUTE BY HASH(...)` 列，与 Join 条件列逐一比对
3. **更新统计信息**：`ANALYZE TABLE`，修复行数估算偏差后重新执行 EXPLAIN，确认 Join 策略是否切换
4. **小维度表改复制表**：行数 &lt; 10 万的维度表，用 REPLICATED 彻底消除 Broadcast/Redistribute
5. **高频 Join 对齐分布键**：建表时统一两表的分布键为 Join 键，这是从根本上消除数据移动的方案
6. **CTE 先过滤再 Join**：无法修改表结构时，在 CTE 内先缩减行数，再执行 Join，降低 Redistribute 代价



性能调优

GBase 8a 多表 Join 执行计划：Hash Join、Broadcast 与 Redistribute 的选择依据

GBase 8a 多表 Join 执行计划：Hash Join、Broadcast 与 Redistribute 的选择依据

评论

热门帖子