如何实现会话级临时表_ON COMMIT PRESERVE ROWS特性-Oracle-PHP中文网

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 实际上是冗余的——它只在 create temporary table 声明为 on commit delete rows 后才可被显式覆盖。但很多人误以为加了它就能“延长生命周期”，结果发现提交后数据还在，或反而丢了，根源常是没意识到：临时表本身不参与事务回滚，其“提交行为”仅影响 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`，替代方案要绕开事务绑定

MySQL 的 CREATE TEMPORARY TABLE 本质是会话级、非事务性对象，天生就“提交也不删”，所以它压根不支持 ON COMMIT 子句。强行照搬 PostgreSQL 写法会直接报错：ERROR 1064 (42000): You have an error in your SQL syntax。这时候得换思路：

用普通表 + 命名规则 + 定期清理：比如表名带 _tmp_<pid></pid> 或 _tmp_<connection_id></connection_id>，应用层负责建和删
用内存表（ENGINE=MEMORY）+ 显式 DROP TEMPORARY TABLE 控制生命周期，但注意 MEMORY 表不支持 BLOB/TEXT，且数据全在内存，OOM 风险高
若必须和事务强绑定（如中间计算结果），只能用普通表配合唯一 session ID 字段 + 应用层手动清理，别指望数据库自动收尾

Oracle 的 `ON COMMIT PRESERVE ROWS` 要配 `GLOBAL TEMPORARY TABLE`

Oracle 是少数真正实现该语法的数据库，但它要求前置条件严格：必须是 GLOBAL TEMPORARY TABLE，且建表时明确指定 ON COMMIT PRESERVE ROWS。漏掉 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 两种事务模型。任何试图用统一 SQL 模板适配三者的做法，最终都会在某个环境里栽跟头。

ORM 层硬塞 ON COMMIT PRESERVE ROWS 到 MySQL 或 SQL Server（它也不支持），必然报错
用配置开关切换建表语句？可行，但要注意：SQL Server 的临时表（#t）连 DDL 都不能跨批执行，CREATE #t 和后续 INSERT 必须在同一 batch
最稳妥的做法：把临时表逻辑下沉到 DAO 层，按 databaseProductName 分支处理，建表、填充、清理全部由具体方言实现

会话级临时表的“临时性”不是靠语法糖保证的，而是靠数据库内核对对象生命周期的定义方式。抄一行 SQL 解决不了问题，得先看清自己用的是哪套规则。