活动专区

活动公告

上车！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 现场，常见一句抱怨：「同一条 SQL，昨天还能跑，今天突然变慢」。除了锁等待、分布键不合理，还有一个高频根因——**统计信息过旧或缺失**，优化器按「猜的行数」选了 **REDISTRIBUTE + 大表广播** 这类昂贵路径。

8a 是 MPP：统计信息通常要在 **协调节点收集、下发到各数据节点** 后，全局计划才相对靠谱。本文说明何时做 `ANALYZE`、怎么快速判断「计划是否被统计信息误导」，并给可执行检查清单。

## 一、统计信息影响什么

优化器主要用统计信息估计：

| 估计项 | 计划上的典型后果 |
|--------|------------------|
| 行数、选择性 | 选 Hash Join 还是 NestLoop；是否广播小表 |
| 列 distinct 值 | 分布键倾斜时是否仍选重分布 |
| 表/分区大小 | 是否做分区裁剪、是否漏裁 |

**统计为空或极旧** 时，8a 往往倾向「保守大计划」：多 Motion、多洗牌，表现为 **突然变慢且无锁**。

## 二、什么时候必须 ANALYZE

建议在以下时机对 **大表** 做统计收集（语法以版本文档为准）：

1. **批量加载 / 大量 INSERT 后**
2. **大规模 DELETE/UPDATE 后**（若版本支持统计失效）
3. **新建表首次上线前**
4. **慢 SQL 排查中 EXPLAIN 行数明显离谱**（如百万级表估成几千行）
5. **改分布键或重建表后**

```sql
-- 示例（表名、选项以现场为准）
ANALYZE TABLE fact_orders;
ANALYZE TABLE dim_customer;
```

部分版本支持 **采样比例、按分区收集**；大表可在维护窗口用 **采样 ANALYZE** 降低开销，再对核心 SQL 做计划对比。

## 三、用 EXPLAIN 判断「统计是否不可信」

对问题 SQL 执行：

```sql
EXPLAIN
SELECT c.region, SUM(o.amt)
FROM fact_orders o
JOIN dim_customer c ON o.cust_id = c.cust_id
WHERE o.dt >= DATE '2026-05-01'
GROUP BY c.region;
```

阅读时重点看：

1. **估算行数** 是否与常识差一个数量级以上（需结合 `COUNT(*)`、分区裁剪后行数）
2. 是否出现 **不必要的 BROADCAST 大维表**
3. 是否在 **分布键已对齐** 时仍 **REDISTRIBUTE**

若 `ANALYZE` 后计划中 Motion 减少、估算行数接近实测，多半统计信息是主因之一。

## 四、案例：加载后未 ANALYZE 导致广播维表

**场景**：`fact_orders` 约 5 亿行，按 `cust_id` 分布；`dim_customer` 约 200 万行，夜间加载后 **未 ANALYZE**。白天关联查询从 20s 恶化到 3 分钟+。

**EXPLAIN 现象（文字描述）**：

- 优化器将 `dim_customer` 估成 **极小表** → **BROADCAST** 到所有节点
- 实际维表并不小，广播成本极高

**处理**：

1. 对 `fact_orders`、`dim_customer` 执行 `ANALYZE`
2. 若维表确实较小，可评估 **复制表** 替代广播（视版本与容量）
3. 再次 `EXPLAIN`，确认 Motion 与 Join 顺序变化

**结果**：计划改为更合理的 Join 方式，耗时回到数十秒级。

## 五、与分布键、慢 SQL 排查的衔接

| 顺序 | 动作 |
|------|------|
| 1 | `SHOW PROCESSLIST` 排除锁等待 |
| 2 | `EXPLAIN` 看 Motion 与估算行数 |
| 3 | 查 DDL：分布键、分区键 |
| 4 | 统计可疑则 **ANALYZE**，前后对比计划 |
| 5 | 仍慢再改 SQL / 中间表 / 索引（单节点） |

统计信息 **解决不了** 分布键与 Join 键不一致；但能避免「明明对齐却仍广播/洗牌」的 **误判**。

## 六、运维建议清单

```text
[1] 大表加载脚本末尾增加 ANALYZE 步骤（或触发异步收集任务）
[2] 核心表记录上次 ANALYZE 时间，超期告警
[3] 慢 SQL 案例库保存：ANALYZE 前后 EXPLAIN 截图
[4] 变更窗口：先 ANALYZE 再放开 BI 查询
[5] 勿在统计极旧时做「上线性能签字」
```

## 小结

GBase 8a 的性能问题里，**统计信息**属于低成本、高收益的一关。把 `ANALYZE` 纳入加载与变更流程，并用 `EXPLAIN` 对比收集前后的 Motion 与行数估计，能少踩很多「SQL 没变、计划却变了」的坑。建议与 **分布键设计、锁排查** 分册沉淀案例，方便团队复用。




性能调优

GBase 8a 统计信息与 ANALYZE：避免优化器「猜错」执行计划

GBase 8a 统计信息与 ANALYZE：避免优化器「猜错」执行计划

评论

热门帖子