活动专区

活动公告

上车！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 临时表在会话中间结果处理里的使用边界

我最近整理 GBase 8a 的一些 SQL 写法时，发现临时表这个对象很容易被低估。很多人提到中间结果，第一反应是建一张普通表，跑完再删；也有人把临时表当成“随便用、不会留下痕迹”的工具。真正落到现场时，这两种理解都不够稳。临时表确实适合承接会话内的中间结果，但它不是无成本对象，也不是所有临时加工场景都适合直接上。

GBase 8a MPP Cluster 里，临时表被限制在当前连接中，连接关闭后会自动删除。这个特点对排查和开发都很有价值：同名临时表可以在不同连接里同时存在，也不会和已有同名普通表直接冲突。但这里有一个容易踩的点：临时表会在当前连接里隐藏同名普通表。现场如果连接没有切干净，或者脚本复用了连接，很可能出现“我查的表不是我以为的那张表”。

## 临时表适合解决什么问题

我自己理解下来，临时表更适合三类场景。

第一类是复杂加工链路里的中间结果沉淀。比如一个月度结算任务，需要先把交易明细按客户、机构、产品做几轮过滤，再和维表做校验。如果每一步都写成一个超长 SQL，后续排查会很难。把关键中间结果落到临时表里，能把问题切小。

第二类是会话级调试。排查数据差异时，我经常会把可疑数据集保存到临时表，然后反复做对比，而不是每次重新跑原始查询。

第三类是避免污染正式库对象。有些临时加工表只在一次会话里有意义，建成普通表会留下清理负担，表名管理也容易混乱。

| 场景 | 适合临时表吗 | 原因 | 注意点 |
|---|---|---|---|
| 一次性数据核对 | 适合 | 只在当前连接内使用 | 连接断开后结果消失 |
| 多步骤加工调试 | 适合 | 便于拆分复杂 SQL | 控制数据量和字段数 |
| 跨会话共享中间结果 | 不适合 | 临时表只属于当前连接 | 用普通表或结果表 |
| 需要备份保留 | 不适合 | 临时表不能被备份 | 改用正式对象 |
| 应用连接池复用 | 谨慎 | 临时对象生命周期和连接绑定 | 必须显式清理 |

这张表里我最关注“连接池复用”。很多开发调试时是一条连接跑完就退出，但应用侧连接池不会这么做。连接如果被复用，临时表就可能在同一个物理连接里继续存在，影响下一段逻辑。

## 同名对象隐藏是最容易被忽略的点

GBase 8a 文档里提到，两个不同连接可以使用同一个临时表名而不会冲突，也不会与现有同名表冲突，现有表会被隐藏，直到临时表被删除。这个设计在功能上很方便，但排查时需要格外小心。

下面这个例子很贴近现场：

```sql
-- 正式业务表
CREATE TABLE rpt_work.tmp_check_result (
    cust_id     bigint,
    acct_month  varchar(6),
    diff_amt    decimal(18,2)
) DISTRIBUTED BY ('cust_id');

-- 某个排查会话里又创建了同名临时表
CREATE TEMPORARY TABLE rpt_work.tmp_check_result (
    cust_id     bigint,
    acct_month  varchar(6),
    diff_amt    decimal(18,2),
    check_tag   varchar(32)
) DISTRIBUTED BY ('cust_id');

INSERT INTO rpt_work.tmp_check_result
VALUES (1002003001, '202604', 18.50, 'session_check');

SELECT * FROM rpt_work.tmp_check_result;
```

在当前连接里，查询到的是临时表，不是正式表。换一个连接后，同样的 SQL 可能查到正式表。这种现象如果没有提前意识到，会让排查过程变得非常混乱。

我实际处理时一般会给临时表加明显前缀，例如 `tmp_sess_`、`tmp_chk_`，并避免和正式表命名空间重叠。

| 命名方式 | 风险 | 建议 |
|---|---|---|
| `tmp_check_result` | 容易和正式对象撞名 | 加会话或任务标识 |
| `result_202604` | 看不出是否临时对象 | 不建议 |
| `tmp_sess_recon_0427` | 可读性较好 | 适合手工排查 |
| `tmp_app_stage` | 应用复用时有残留风险 | 配合显式 DROP |

## 临时表不是免治理对象

临时表会话结束后自动删除，但这不代表使用过程没有资源成本。GBase 8a 是 MPP 架构，临时表如果承接大量数据，仍然会占用节点上的存储、执行资源和网络传输资源。尤其是把大表过滤结果直接塞进临时表时，不能只想着“反正会自动删”。

我一般会从三个角度控制临时表使用。

第一，字段只保留后续要用的列。不要 `SELECT *` 直接落临时表。

第二，尽量在写入临时表前完成必要过滤。中间表越宽、越大，后续 Join、聚合成本越高。

第三，分布方式要服务后续操作。临时表也可以指定 `DISTRIBUTED BY` 或 `REPLICATED`，不能默认随便建。

```sql
CREATE TEMPORARY TABLE tmp_sess_pay_202604 (
    cust_id      bigint,
    org_id       varchar(16),
    pay_month    varchar(6),
    pay_amt      decimal(18,2)
) DISTRIBUTED BY ('cust_id');

INSERT INTO tmp_sess_pay_202604
SELECT cust_id,
       org_id,
       pay_month,
       SUM(pay_amt) AS pay_amt
  FROM ods_pay_detail
 WHERE pay_month = '202604'
   AND pay_status = 'S'
 GROUP BY cust_id, org_id, pay_month;
```

这里没有把明细全塞进去，而是先按后续需要的粒度聚合。临时表不是垃圾桶，它更像一次排查里的工作台。工作台上放什么，直接影响后面处理效率。

## 分布方式要跟后续使用对齐

临时表的分布方式经常被忽略。很多人建临时表时只关心字段，没想过后续要怎么关联。GBase 8a 场景里，如果临时表后续要和大事实表按客户号关联，我会优先考虑按客户号分布；如果临时表数据很小、后续要和多张大表关联，可以考虑复制表思路，但要控制数据量。

| 临时表用途 | 推荐分布思路 | 原因 | 风险 |
|---|---|---|---|
| 和大表按客户关联 | `DISTRIBUTED BY ('cust_id')` | 降低数据重分布 | cust_id 倾斜会影响节点 |
| 小维表临时补充 | `REPLICATED` | 避免多次广播 | 数据量不能大 |
| 仅当前会话单表过滤 | 按主要过滤或关联列 | 服务后续查询 | 不要盲目随机 |
| 临时汇总结果 | 按汇总主键分布 | 便于二次关联 | 汇总键过少可能倾斜 |

我不建议把临时表分布方式当成固定模板。现场要看后续 SQL 怎么写。如果只是单次查看结果，分布方式影响不大；如果后续还有 Join、聚合、导出，分布方式就会变成关键细节。

## 应用脚本里要显式清理

虽然临时表会在连接关闭时自动删除，但我在脚本里仍然倾向于显式 `DROP TEMPORARY TABLE`。原因很简单：不是所有脚本都能保证连接马上关闭，也不是所有异常分支都能自然走到退出。

一个比较稳的写法是开始前先尝试清理，再创建临时表，结束后再清理一次。

```sql
DROP TEMPORARY TABLE IF EXISTS tmp_sess_order_delta;

CREATE TEMPORARY TABLE tmp_sess_order_delta (
    order_id      bigint,
    cust_id       bigint,
    order_day     date,
    delta_amt     decimal(18,2)
) DISTRIBUTED BY ('cust_id');

INSERT INTO tmp_sess_order_delta
SELECT order_id,
       cust_id,
       order_day,
       pay_amt - refund_amt AS delta_amt
  FROM dwd_order_day
 WHERE order_day &gt;= '2026-04-01'
   AND order_day &lt;  '2026-05-01'
   AND pay_amt &lt;&gt; refund_amt;

SELECT cust_id, SUM(delta_amt) AS sum_delta
  FROM tmp_sess_order_delta
 GROUP BY cust_id
 HAVING SUM(delta_amt) &lt;&gt; 0;

DROP TEMPORARY TABLE IF EXISTS tmp_sess_order_delta;
```

Shell 脚本里也可以把清理逻辑放到退出路径中：

```bash
#!/bin/bash
set -e

DB_HOST="192.0.2.41"
DB_USER="etl_check"
DB_NAME="risk_dw"

gbase -h"${DB_HOST}" -u"${DB_USER}" "${DB_NAME}" &lt;&lt;'SQL'
DROP TEMPORARY TABLE IF EXISTS tmp_sess_risk_order;

CREATE TEMPORARY TABLE tmp_sess_risk_order (
    cust_id bigint,
    risk_day date,
    risk_score decimal(10,4)
) DISTRIBUTED BY ('cust_id');

INSERT INTO tmp_sess_risk_order
SELECT cust_id, risk_day, risk_score
  FROM ads_risk_score_day
 WHERE risk_day = '2026-04-30'
   AND risk_score &gt;= 0.85;

SELECT COUNT(*) AS high_risk_cnt
  FROM tmp_sess_risk_order;

DROP TEMPORARY TABLE IF EXISTS tmp_sess_risk_order;
SQL
```

我自己更倾向于把临时表看成脚本内部变量，而不是数据库长期对象。变量用完要释放，临时表也是一样。

## 常见坑和处理建议

| 常见坑 | 现场表现 | 原因 | 建议 |
|---|---|---|---|
| 临时表和正式表同名 | 同一 SQL 不同连接结果不同 | 当前连接隐藏正式表 | 临时表命名加专用前缀 |
| 应用连接池复用 | 下一次请求看到上次临时表 | 连接未关闭 | 开始和结束都显式 DROP |
| `SELECT *` 建临时表 | 中间结果过宽过大 | 字段未裁剪 | 只保留后续必要字段 |
| 不指定分布方式 | 后续 Join 成本高 | 没贴合关联键 | 按后续访问方式设计 |
| 把临时表当结果表 | 连接断开数据丢失 | 生命周期误判 | 需要保留时用普通表 |
| 期望备份临时表 | 备份中找不到 | 临时表不参与备份 | 不承载长期结果 |

## 结尾总结

GBase 8a 临时表很适合承接会话内中间结果，也很适合排查复杂 SQL 时把问题拆小。但它的边界也很清楚：生命周期绑定连接，不能备份，可能隐藏同名正式表，数据量大时仍然会带来资源成本。

我最近整理下来觉得，临时表用得好不好，关键不在语法，而在对象边界。命名要和正式表拉开，分布方式要和后续 SQL 对齐，脚本里要显式清理，应用连接池场景要格外谨慎。把这些细节处理好，临时表会是很实用的排查和加工工具；如果只把它当成“临时凑一下”的对象，后面反而容易制造新的现场问题。

## 参考资料

```text
[1] GBase 8a DDL语法 CREATE TEMPORARY TABLE https://www.gbase.cn/docs/gbase-8a/%E4%BA%A7%E5%93%81%E6%89%8B%E5%86%8C/dm-database-management-guide/dm-sql-reference/dm-syntax-ddl
[2] GBase 8a 系统表 https://www.gbase.cn/docs/gbase-8a/%E4%BA%A7%E5%93%81%E6%89%8B%E5%86%8C/dm-database-management-guide/dm-system-table/
[3] GBase 社区优质文章区 https://www.gbase.cn/community/section/11
```



运维管理

GBase 8a 临时表在会话中间结果处理里的使用边界

GBase 8a 临时表在会话中间结果处理里的使用边界

评论

热门帖子