GBase 8a 临时表在会话中间结果处理里的使用边界
GBase 8a 临时表在会话中间结果处理里的使用边界
我最近整理 GBase 8a 的一些 SQL 写法时，发现临时表这个对象很容易被低估。很多人提到中间结果，第一反应是建一张普通表，跑完再删；也有人把临时表当成“随便用、不会留下痕迹”的工具。真正落到现场时，这两种理解都不够稳。临时表确实适合承接会话内的中间结果，但它不是无成本对象，也不是所有临时加工场景都适合直接上。
GBase 8a MPP Cluster 里，临时表被限制在当前连接中，连接关闭后会自动删除。这个特点对排查和开发都很有价值：同名临时表可以在不同连接里同时存在，也不会和已有同名普通表直接冲突。但这里有一个容易踩的点：临时表会在当前连接里隐藏同名普通表。现场如果连接没有切干净，或者脚本复用了连接，很可能出现“我查的表不是我以为的那张表”。
临时表适合解决什么问题
我自己理解下来，临时表更适合三类场景。
第一类是复杂加工链路里的中间结果沉淀。比如一个月度结算任务，需要先把交易明细按客户、机构、产品做几轮过滤，再和维表做校验。如果每一步都写成一个超长 SQL，后续排查会很难。把关键中间结果落到临时表里，能把问题切小。
第二类是会话级调试。排查数据差异时，我经常会把可疑数据集保存到临时表，然后反复做对比，而不是每次重新跑原始查询。
第三类是避免污染正式库对象。有些临时加工表只在一次会话里有意义，建成普通表会留下清理负担，表名管理也容易混乱。
| 场景 | 适合临时表吗 | 原因 | 注意点 |
|---|---|---|---|
| 一次性数据核对 | 适合 | 只在当前连接内使用 | 连接断开后结果消失 |
| 多步骤加工调试 | 适合 | 便于拆分复杂 SQL | 控制数据量和字段数 |
| 跨会话共享中间结果 | 不适合 | 临时表只属于当前连接 | 用普通表或结果表 |
| 需要备份保留 | 不适合 | 临时表不能被备份 | 改用正式对象 |
| 应用连接池复用 | 谨慎 | 临时对象生命周期和连接绑定 | 必须显式清理 |
这张表里我最关注“连接池复用”。很多开发调试时是一条连接跑完就退出，但应用侧连接池不会这么做。连接如果被复用，临时表就可能在同一个物理连接里继续存在，影响下一段逻辑。
同名对象隐藏是最容易被忽略的点
GBase 8a 文档里提到，两个不同连接可以使用同一个临时表名而不会冲突，也不会与现有同名表冲突，现有表会被隐藏，直到临时表被删除。这个设计在功能上很方便，但排查时需要格外小心。
下面这个例子很贴近现场：
-- 正式业务表CREATETABLErpt_work.tmp_check_result(cust_idbigint,acct_monthvarchar(6),diff_amtdecimal(18,2))DISTRIBUTEDBY('cust_id');-- 某个排查会话里又创建了同名临时表CREATETEMPORARYTABLErpt_work.tmp_check_result(cust_idbigint,acct_monthvarchar(6),diff_amtdecimal(18,2),check_tagvarchar(32))DISTRIBUTEDBY('cust_id');INSERTINTOrpt_work.tmp_check_resultVALUES(1002003001,'202604',18.50,'session_check');SELECT*FROMrpt_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，不能默认随便建。
CREATETEMPORARYTABLEtmp_sess_pay_202604(cust_idbigint,org_idvarchar(16),pay_monthvarchar(6),pay_amtdecimal(18,2))DISTRIBUTEDBY('cust_id');INSERTINTOtmp_sess_pay_202604SELECTcust_id,org_id,pay_month,SUM(pay_amt)ASpay_amtFROMods_pay_detailWHEREpay_month='202604'ANDpay_status='S'GROUPBYcust_id,org_id,pay_month;这里没有把明细全塞进去，而是先按后续需要的粒度聚合。临时表不是垃圾桶，它更像一次排查里的工作台。工作台上放什么，直接影响后面处理效率。
分布方式要跟后续使用对齐
临时表的分布方式经常被忽略。很多人建临时表时只关心字段，没想过后续要怎么关联。GBase 8a 场景里，如果临时表后续要和大事实表按客户号关联，我会优先考虑按客户号分布；如果临时表数据很小、后续要和多张大表关联，可以考虑复制表思路，但要控制数据量。
| 临时表用途 | 推荐分布思路 | 原因 | 风险 |
|---|---|---|---|
| 和大表按客户关联 | DISTRIBUTED BY ('cust_id') | 降低数据重分布 | cust_id 倾斜会影响节点 |
| 小维表临时补充 | REPLICATED | 避免多次广播 | 数据量不能大 |
| 仅当前会话单表过滤 | 按主要过滤或关联列 | 服务后续查询 | 不要盲目随机 |
| 临时汇总结果 | 按汇总主键分布 | 便于二次关联 | 汇总键过少可能倾斜 |
我不建议把临时表分布方式当成固定模板。现场要看后续 SQL 怎么写。如果只是单次查看结果，分布方式影响不大；如果后续还有 Join、聚合、导出，分布方式就会变成关键细节。
应用脚本里要显式清理
虽然临时表会在连接关闭时自动删除，但我在脚本里仍然倾向于显式DROP TEMPORARY TABLE。原因很简单：不是所有脚本都能保证连接马上关闭，也不是所有异常分支都能自然走到退出。
一个比较稳的写法是开始前先尝试清理，再创建临时表，结束后再清理一次。
DROPTEMPORARYTABLEIFEXISTStmp_sess_order_delta;CREATETEMPORARYTABLEtmp_sess_order_delta(order_idbigint,cust_idbigint,order_daydate,delta_amtdecimal(18,2))DISTRIBUTEDBY('cust_id');INSERTINTOtmp_sess_order_deltaSELECTorder_id,cust_id,order_day,pay_amt-refund_amtASdelta_amtFROMdwd_order_dayWHEREorder_day>='2026-04-01'ANDorder_day<'2026-05-01'ANDpay_amt<>refund_amt;SELECTcust_id,SUM(delta_amt)ASsum_deltaFROMtmp_sess_order_deltaGROUPBYcust_idHAVINGSUM(delta_amt)<>0;DROPTEMPORARYTABLEIFEXISTStmp_sess_order_delta;Shell 脚本里也可以把清理逻辑放到退出路径中：
#!/bin/bashset-eDB_HOST="192.0.2.41"DB_USER="etl_check"DB_NAME="risk_dw"gbase -h"${DB_HOST}"-u"${DB_USER}""${DB_NAME}"<<'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 >= 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 对齐，脚本里要显式清理，应用连接池场景要格外谨慎。把这些细节处理好，临时表会是很实用的排查和加工工具；如果只把它当成“临时凑一下”的对象，后面反而容易制造新的现场问题。
参考资料
[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