Java中CREATE GLOBAL TEMPORARY TABLE失败是因权限不足或会话隔离导致“表不存在”，而非语法错误；Oracle要求GTT必须由DBA预建，Java仅能执行DML；ON COMMIT DELETE ROWS适用于单事务内临时数据，PRESERVE ROWS在连接池下易致数据泄漏；批量插入须用addBatch+APPEND Hint，且需及时收集统计信息并预先创建索引。
为什么Java里直接CREATE GLOBAL TEMPORARY TABLE会失败
不是语法错，而是权限或会话隔离导致的“表不存在”报错。oracle的global temporary table必须在数据库端提前建好（ddl），不能在java中用create global temporary table语句动态创建——jdbc连接默认不具备ddl执行权限，且临时表定义是全局对象，需dba或具备create any table权限的用户预置。
- 开发阶段：让DBA执行一次
CREATE GLOBAL TEMPORARY TABLE tmp_calc_order (order_id NUMBER, amt NUMBER) ON COMMIT DELETE ROWS - Java代码里只做DML：
INSERT INTO tmp_calc_order、SELECT * FROM tmp_calc_order - 别试图在
PreparedStatement里拼接CREATE语句，Oracle会抛ORA-01031: insufficient privileges
ON COMMIT DELETE ROWS 和 PRESERVE ROWS 怎么选
关键看Java业务逻辑是否跨事务提交。Spring里一个@Transactional方法就是一个事务边界；若中间数据只用于该方法内多次查询（如先校验再聚合），选ON COMMIT DELETE ROWS；若需在多个HTTP请求间复用（如用户会话级缓存权限树），才用ON COMMIT PRESERVE ROWS。
-
ON COMMIT DELETE ROWS：每次commit后自动清空，适合单次业务流，避免残留数据污染后续调用 -
ON COMMIT PRESERVE ROWS：数据存活到连接关闭，但Java连接池（如HikariCP）会复用物理连接 → 不同线程可能读到旧数据，极易出错 - 真实踩坑：用
PRESERVE ROWS表做分页缓存，结果第二页查出第一页的数据，因为连接被池复用了
Java批量插入临时表的性能陷阱
普通executeUpdate()逐条插万级数据，慢得离谱。临时表虽不写redo，但每行仍要走SQL解析+行锁+内存分配路径。必须用批处理+绑定变量，且注意Oracle对GTT的APPEND Hint支持有限。
- 正确姿势：
PreparedStatement ps = conn.prepareStatement("INSERT /*+ APPEND */ INTO tmp_calc_order VALUES (?, ?)");→ps.addBatch()→ps.executeBatch() - 错误姿势：用
Statement拼字符串插入，触发硬解析，还可能SQL注入 - 注意：
APPEND在GTT上有效，但仅对直接路径插入加速，且要求表无索引（否则Hint失效）；如有索引，先删索引、插完再建
临时表索引和统计信息怎么配才不翻车
GTT的索引是会话级私有对象，但统计信息默认为空 → 优化器总以为表只有1行，JOIN大表时疯狂选错执行计划。Java里不能依赖DBA手动收集，得在插入后主动触发。
- 插入完立刻执行：
conn.createStatement().execute("BEGIN DBMS_STATS.GATHER_TABLE_STATS(ownname=>USER, tabname=>'TMP_CALC_ORDER'); END;") - 索引必须在建表时就创建（不能Java里动态
CREATE INDEX），否则批插后查询极慢 - 别信“GTT不用索引”，如果后续
WHERE order_id IN (...)或JOIN，没索引就是全表扫描
临时表不是“随便建个表放中间数据”的捷径，它的生命周期、索引可见性、统计信息更新都和Java连接池行为强耦合。最常被忽略的是：连接复用下PRESERVE ROWS等于数据泄漏，而没收集统计信息会让优化器彻底失明。
立即学习“Java免费学习笔记（深入）”；
