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解决不了问题，关键在于先看清楚，你正在使用的数据库，遵循的是哪一套游戏规则。
