oracle全局临时表（gtt）结构永久存在，数据按on commit delete/preserve rows语义自动清空；须显式指定on commit子句，避免默认delete rows导致数据“莫名消失”，且应关注temp表空间真实压力源为排序/哈希操作而非gtt本身。
oracle里临时表不用每次建删，全局临时表（gtt）一旦创建就永久存在，数据只随会话或事务自动清空；真正要管的是它的生命周期语义和底层 temp 表空间压力。
CREATE GLOBAL TEMPORARY TABLE 时 ON COMMIT 必须显式指定
不写 ON COMMIT 子句时，Oracle 默认按 ON COMMIT DELETE ROWS 处理，但这个行为容易被忽略，导致数据“莫名消失”——比如在存储过程中插入后没立刻查，等 commit 后再查就空了。
-
ON COMMIT DELETE ROWS：适合单次事务内分步处理，如批量校验+提交前汇总，commit 或 rollback 后自动清空 -
ON COMMIT PRESERVE ROWS：适合跨多个事务的会话级中间状态，比如报表生成中多步查询共用一张临时表，直到用户登出才释放 - 建表语句一旦执行成功，表结构就注册进数据字典，后续所有会话都能直接
INSERT/SELECT，无需重复CREATE - 错误示例：
CREATE GLOBAL TEMPORARY TABLE tmp_log (msg VARCHAR2(200))—— 看似合法，但语义模糊，应明确补上ON COMMIT PRESERVE ROWS或DELETE ROWS
PL/SQL 中别用 DROP + CREATE 做“重置”，改用 TRUNCATE 或 INSERT /*+ APPEND */
在存储过程里频繁 DROP TABLE 再 CREATE GLOBAL TEMPORARY TABLE 不仅慢，还可能报 ORA-14452（尝试修改正在被引用的临时表），尤其当多个过程并发调用时。
- 正确做法：首次建好后，后续只需
TRUNCATE TABLE tmp_tab清空当前会话数据（对PRESERVE ROWS表也有效） - 若需重填且数据量大，用
INSERT /*+ APPEND */ INTO tmp_tab SELECT ...，避免 redo 日志开销（临时表本身不写 redo，但常规 insert 仍走 buffer cache） - 判断表是否存在？没必要。直接
TRUNCATE即可——如果表不存在，会报ORA-00942，捕获异常后建表更安全，比先查user_tables再分支更简洁 - 反模式示例：用
EXECUTE IMMEDIATE 'DROP TABLE tmp_tab'→EXECUTE IMMEDIATE 'CREATE GLOBAL TEMPORARY TABLE ...'—— 锁争用高、DDL 解析开销大、易出错
临时表数据看不见？检查是否连错了会话，或误用了事务级生命周期
开发时最常遇到：“我明明 INSERT 了，SELECT 却是空的”。这不是 bug，是机制在起作用。
- 确认连接工具是否复用连接池（如 JDBC 的 connection pool）：同一逻辑“用户”可能被分配到不同物理会话，
PRESERVE ROWS表的数据不会跨会话共享 - 执行过
COMMIT？如果是ON COMMIT DELETE ROWS表，commit 后数据立即不可见，哪怕还在同一个会话里 - 用
SELECT * FROM v$session WHERE sid = SYS_CONTEXT('USERENV', 'SID')查当前会话 ID，再对比插入/查询时的 SID 是否一致 - 不要在 SQL*Plus 或 PL/SQL Developer 的“新窗口”里查——那是个新会话，必然看不到原会话的临时表数据
临时表撑爆 TEMP 表空间？问题不在 GTT 本身，而在排序/哈希操作溢出
很多人看到 ORA-01652: unable to extend temp segment 就以为是临时表写多了，其实 90% 场景跟 CREATE GLOBAL TEMPORARY TABLE 无关——是 ORDER BY、GROUP BY、HASH JOIN 这些操作把 PGA 填满后，被迫写入 TEMP 表空间造成的。
- 全局临时表（GTT）的数据存储位置确实是 TEMP 表空间，但它只占很小一部分；真正的“大户”是排序段（sort segment）和哈希区（hash area）
- 查真实压力源：
SELECT sql_id, operation_type, tempseg_size/1024/1024 AS mb FROM v$tempseg_usage t JOIN v$sql s ON t.sql_id = s.sql_id ORDER BY tempseg_size DESC - 优化方向优先级：调大
PGA_AGGREGATE_TARGET→ 改写 SQL 减少排序量 → 最后才是扩容 TEMP 文件（ALTER DATABASE TEMPFILE '/path/to/temp01.dbf' RESIZE 2G） - 注意：
TRUNCATE TABLE对 GTT 不释放 TEMP 空间，只有会话结束或实例重启才会回收——这是设计使然，不是泄漏
临时表真正的复杂点不在语法，而在于它横跨两个层面：上层是会话/事务的数据可见性控制，下层是 TEMP 表空间的物理资源竞争。写 PL/SQL 时盯住 ON COMMIT 语义，运维时盯住 v$tempseg_usage 而不是 dba_temp_files 的总大小。
