如何实现会话级临时表_ON COMMIT PRESERVE ROWS特性
PostgreSQL中ON COMMIT PRESERVE ROWS是冗余的，默认即此行为；它仅在显式声明ON COMMIT DELETE ROWS后才可覆盖，且不可ALTER修改；MySQL不支持该子句，Oracle则要求GLOBAL TEMPORARY TABLE。
PostgreSQL 里 ON COMMIT PRESERVE ROWS 不起作用？检查事务模式
很多开发者第一次在PostgreSQL里用ON COMMIT PRESERVE ROWS时，可能会感到困惑：明明加了这句，怎么感觉跟没加一样？其实，问题的关键就在于理解PostgreSQL临时表的默认行为。
免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈
简单来说，PostgreSQL的临时表天生就是“会话级”的。这意味着，ON COMMIT PRESERVE ROWS这个子句在PostgreSQL里其实是冗余的——它描述的就是系统默认的行为。这个子句真正起作用的地方，是在你创建临时表时已经声明了ON COMMIT DELETE ROWS之后，想用一个新的CREATE语句去覆盖它。但这里有个常见的“坑”：已经存在的临时表，其提交行为是无法通过ALTER TABLE来修改的。
所以，当你发现提交事务后数据还在（或者你期望它被清空时反而没清空），根源往往不是语法错误，而是没搞清楚临时表与事务的关系。需要明确一点：临时表本身不参与常规的事务回滚，它的“提交行为”特指在COMMIT这个动作发生时，是否自动清空表中的数据行，而且这个特性只对声明了ON COMMIT DELETE ROWS的临时表有效。
CREATE TEMP TABLE t(x int) ON COMMIT PRESERVE ROWS等价于不写该子句（PostgreSQL 默认行为）- 真正需要它的地方，是你先设了
ON COMMIT DELETE ROWS，后续想改语义——但注意：不能 ALTER 修改已存在的临时表的 commit action - 如果在函数内或匿名块中建临时表，且该函数用
SECURITY DEFINER，还要确认当前用户有TEMP权限，否则建表失败但错误可能被静默吞掉
MySQL 没有 ON COMMIT PRESERVE ROWS，替代方案要绕开事务绑定
如果你从PostgreSQL转向MySQL，想把ON COMMIT PRESERVE ROWS这套逻辑搬过去，那肯定会碰壁。MySQL的CREATE TEMPORARY TABLE从设计上就是会话级且非事务性的，数据在会话结束前会一直保留，提交事务对它没有影响。因此，MySQL根本不支持ON COMMIT这个子句。如果你强行写上，等待你的就是一句经典的ERROR 1064 (42000): You ha ve an error in your SQL syntax。
那在MySQL里怎么实现类似的需求呢？通常得换个思路，绕开数据库原生的“事务提交时保留”语义：
- 用普通表 + 命名规则 + 定期清理：比如表名带
_tmp_或_tmp_，应用层负责建和删 - 用内存表（
ENGINE=MEMORY）+ 显式DROP TEMPORARY TABLE控制生命周期，但注意MEMORY表不支持 BLOB/TEXT，且数据全在内存，OOM 风险高 - 若必须和事务强绑定（如中间计算结果），只能用普通表配合唯一 session ID 字段 + 应用层手动清理，别指望数据库自动收尾
Oracle 的 ON COMMIT PRESERVE ROWS 要配 GLOBAL TEMPORARY TABLE
在几个主流数据库中，Oracle是少数真正需要并完整实现ON COMMIT PRESERVE ROWS语法的。但它有个严格的前置条件：这个子句必须和GLOBAL TEMPORARY TABLE（全局临时表）一起使用。漏掉GLOBAL关键字，或者误用旧的TEMPORARY语法，都会导致错误。
- 正确写法：
CREATE GLOBAL TEMPORARY TABLE t(x INT) ON COMMIT PRESERVE ROWS - 错误写法：
CREATE TEMPORARY TABLE t(x INT) ON COMMIT PRESERVE ROWS（报错 ORA-00902） - 注意：这种表的 DDL 会被所有会话共享，但数据完全隔离；
PRESERVE ROWS下，COMMIT不清空，ROLLBACK也不清空，只有会话退出或显式TRUNCATE才清 - 性能上，
PRESERVE ROWS表的数据会一直留在 PGA，长连接容易累积，建议业务逻辑结束时主动TRUNCATE
跨数据库兼容写法不存在，别试图抽象一层
看到这里，你可能已经发现了，不同数据库对“临时表生命周期”的管理哲学差异巨大。PostgreSQL默认就是会话保留；MySQL干脆不支持事务绑定；Oracle则提供了DELETE和PRESERVE两种精细的事务模型。这种底层差异意味着，不存在一套放之四海而皆准的兼容写法。
任何试图在ORM或中间件层用统一SQL模板来适配这三种数据库的做法，最终都会在某个环节出问题。
- ORM 层硬塞
ON COMMIT PRESERVE ROWS到 MySQL 或 SQL Server（它也不支持），必然报错 - 用配置开关切换建表语句？可行，但要注意：SQL Server 的临时表（
#t）连 DDL 都不能跨批执行，CREATE #t和后续INSERT必须在同一 batch - 最稳妥的做法：把临时表逻辑下沉到 DAO 层，按
databaseProductName分支处理，建表、填充、清理全部由具体方言实现
说到底，会话级临时表的“临时性”，并不是靠一句语法糖来保证的，而是由数据库内核对于对象生命周期的根本定义所决定的。直接拷贝一行SQL解决不了问题，关键在于先看清楚，你正在使用的数据库，遵循的是哪一套游戏规则。
热门专题
热门推荐
深度解析《星球大战：摩尔—暗影领主》达斯·摩尔邪恶搭档：间谍机器人Spybot全揭秘！ 全面剖析其独特造型设计、反派角色魅力与标志性呼噜声功能，揭秘它如何成为系列中最具趣味性的新晋角色。Disney+平台每周持续更新剧集。 当经典黑色电影的风格质感，与浩瀚无垠的《星球大战》宇宙相互融合，会诞生出怎样
《天堂：经典》新篇章“巴拉卡斯的藏身处，火龙巢xue”开启事前预约 消息来了：NCsoft旗下的《天堂：经典》已经正式启动了新篇章“巴拉卡斯的藏身处，火龙巢xue”的事前预约活动。对于老玩家而言，这无疑是一个值得关注的重要节点。 核心更新内容前瞻 根据官方安排，NCsoft计划于22日带来两大重磅内
12 0 5版本重磅更新：钥石神话与暗影冠军成就详解！3400分达成攻略与赛季坐骑奖励全解析 暴雪于最新公告中宣布，12 0 5补丁将正式上线两项全新成就——“钥石神话”与“暗影冠军”。这不仅为玩家提供了独特的赛季奖励，更在赛季中后期注入了持续挑战史诗钥石地下城的核心动力。普遍认为，当前“午夜赛季”
NA VI临时招入ComeBack替代ExiT！了解签证问题细节、新阵容名单及ComeBack在EMEA VCT的首秀表现 Natus Vincere的阵容名单上，出现了一个临时的新名字。为了应对Abdullah “ExiT” Al-Twaijri的签证问题，队伍紧急招募了Berkcan “Come
《红色沙漠》专注力掌获取攻略：第4章钢铁山脉西侧学习位置与使用方法，错过可随时返回补学！ 在《红色沙漠》的开放世界中，通过观察环境来领悟新技能，是扩充你战斗与探索技能库最核心的途径。然而，若你一味专注于推进主线剧情，很可能会与一些极为关键的实用技能失之交臂。“专注力掌”便是这样一个技能——它不仅对解