活动专区

活动公告

上车！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「逻辑上只是多表 Join + 排序」，执行时却可能出现 **某台 DataNode 磁盘 IO 飙高、临时目录暴涨**，甚至报 *No space left on device*。MPP 下大结果集无法在单节点内存里完成 Hash Join、Sort、聚合时，优化器会走 **落盘（spill）** 或写 **临时文件**；若分布键不佳、统计信息偏差、或并发大查询叠加，临时空间会在分钟级被吃光。

本文说明 8a 现场如何识别「内存不够→落盘」、如何查哪张表/哪条 SQL 在占空间，以及可落地的缓解手段。

## 一、先判断：是落盘、临时表，还是正常数据文件

磁盘告警时要先分清目录性质，避免误删业务数据：

| 线索 | 更可能原因 | 优先动作 |
|------|------------|----------|
| 仅个别 DN 磁盘满，其他正常 | 数据倾斜 + 本地大排序/落盘 | 看该 DN 上 Top SQL 与 EXPLAIN |
| 所有 DN 同时涨 | 并发大查询、批量 ETL | 限流、错峰、查 PROCESSLIST |
| 临时目录（如 `tmp`/`temp`）暴涨 | Sort/Hash Join spill | 优化 SQL 或扩临时空间 |
| 数据目录均匀增长 | 正常加载/膨胀 | 归档、分区清理，不是落盘问题 |

在 **gccli** 连上 CN 后，先记录告警时间点，再对照该时段 **慢查询日志** 或审计表（若环境已开），缩小到 1～3 条可疑 SQL。

## 二、用 EXPLAIN 看「会不会又大又洗」

落盘往往伴随 **大 REDISTRIBUTE、大 Hash Join、大 Sort**。发布前先对可疑 SQL 做：

```sql
EXPLAIN
SELECT o.dt, c.region, SUM(o.amt)
FROM orders o
JOIN customers c ON o.cust_id = c.id
WHERE o.dt BETWEEN DATE '2026-05-01' AND DATE '2026-05-31'
GROUP BY o.dt, c.region
ORDER BY SUM(o.amt) DESC;
```

阅读计划时重点标：

1. **REDISTRIBUTE 行数级**：Join 键与分布键不一致时，两侧都可能洗牌，临时数据量≈参与 Join 的行数。
2. **Sort / Order By 是否在 Gather 之后**：全局排序常把各 DN 结果汇总再排，CN 或单 DN 压力大。
3. **DISTINCT / GROUP BY 键是否等于分布键**：否则先局部聚合再重分布，中间结果膨胀。

若改分布键、复制小维表、或先按天聚合再 Join 后，计划里 Motion 减少，落盘概率通常明显下降。

```sql
ANALYZE TABLE orders;
ANALYZE TABLE customers;
```

统计信息过旧时，优化器可能选「先广播大表」等激进计划，也会放大临时 IO。

## 三、会话级：谁在跑、跑了多久

```sql
SHOW FULL PROCESSLIST;
```

关注 `Time` 很大且 `State` 含 `Sending data`、`Sorting result`、`Creating sort index` 等（文案以版本为准）。结合 `User`、`Host` 找到对应应用。

需要止血时：

1. 与业务确认后 `KILL QUERY` 超大查询；
2. 临时调低该批任务的并发，而不是先扩盘（扩盘只能治标）。

长事务还会拖住元数据，间接让后续 DDL/统计信息任务排队，加重「越跑越满」的感觉。

## 四、节点级：磁盘与临时目录

在 **告警的 DataNode 主机** 上（需运维权限）：

```bash
# 查看挂载点使用率
df -h

# 找近期变大的目录（路径以现场为准）
du -sh $GBASE_DATA/data_node/tmp/* 2>/dev/null | sort -h | tail -20
```

若 `tmp` 下大量随机名文件、且与某条 SQL 开始时间吻合，基本可认定 spill。清理前 **必须确认无正在使用该目录的活跃查询**，否则可能直接导致 SQL 失败。

规范建议：

- 临时目录与数据目录 **分盘**，避免 spill 拖死数据盘；
- 对 `tmp` 配置监控阈值（如 85% 告警）；
- 批任务窗口与在线查询错开。

## 五、SQL 与模型层缓解（按优先级）

1. **对齐分布键**：高频 Join/Group 键与 `DISTRIBUTED BY` 一致，减少 REDISTRIBUTE 数据量——这是降临时 IO 的第一手段。
2. **先裁剪再 Join**：`WHERE dt` 等过滤尽量下推；能分区裁剪就不要全分片扫。
3. **拆阶段**：大事实表先按天/按键聚合到中间表（分布键不变），再 Join 维表。
4. **控制 SELECT 宽度**：避免 `SELECT *` 参与大 Join，减少_shuffle 字节数。
5. **复制极小维表**：可消除一侧 Motion（注意维表变大后改回 HASH）。
6. **调资源参数**：内存、sort buffer、spill 相关参数以 **官方文档与版本** 为准，在测试环境验证后再上生产；盲目调大内存可能引发 OOM，反而更不稳。

## 六、案例片段：ORDER BY 非分布键导致单 DN Sort 拖尾

**场景**：`orders` 按 `user_id` HASH 分布，业务 SQL 按 `amt` 排序取 Top 100，过滤某天数据后仍有千万级行参与排序。

**EXPLAIN 现象**：各 DN 本地扫描后 **Sort**，再 **Gather** 到 CN 做全局 TopN；某一个 DN 因数据倾斜，本地 Sort 特别久，磁盘临时文件暴涨。

**改法**：

- 若业务允许，改为「先按 `user_id` 本地聚合/取 Top，再汇总」；
- 或建立按查询模式设计的中间表，把排序键纳入预处理；
- 并修正倾斜键（参见数据倾斜排查文）。

改后计划应减少「单侧超大 Sort」，或把排序行数先降下来一个数量级。

## 小结

GBase 8a 磁盘打满不一定是「表太大」，而常常是 **大查询的中间结果与落盘**。用 `EXPLAIN` 盯 Motion 与 Sort，用 `PROCESSLIST` 定位会话，在 DN 上核对 `tmp` 与 `df`，再从分布键、裁剪、分阶段聚合入手减负。把「告警时刻、计划截图、tmp 增长、改法前后耗时」记入案例库，团队以后看到 IO 尖刺会先查 spill，而不是只加磁盘。



性能调优

GBase 8a 大查询落盘与临时空间：磁盘打满时的排查路径

GBase 8a 大查询落盘与临时空间：磁盘打满时的排查路径

评论

热门帖子