先给出几个核心结论：在Java开发中，直接通过JDBC执行CREATE GLOBAL TEMPORARY TABLE语句通常都会失败，原因并非SQL语法错误，而是数据库账户权限不足或会话隔离机制导致——Oracle在这种情况下会报出类似“表不存在”的错误。
Oracle临时表（Global Temporary Table, GTT）属于全局对象，其元数据必须在数据库层面提前定义好，通常由DBA或拥有create any table权限的用户预先创建。Java应用层的JDBC连接默认并不具备DDL（数据定义语言）的执行权限，因此当你在PreparedStatement中拼接一条CREATE GLOBAL TEMPORARY TABLE语句时，会直接抛出ORA-01031: insufficient privileges错误。
因此，合理的做法如下：
- 在开发阶段，由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语句，这只会走入死胡同。
ON COMMIT DELETE ROWS还是PRESERVE ROWS，如何选择
这个选择直接取决于业务逻辑是否跨事务提交。在典型的Spring应用中，标注了@Transactional的方法就是一个完整的事务边界。如果中间数据只用于该方法内部的多次查询（例如先校验再聚合），那么选择ON COMMIT DELETE ROWS就是正确的——每次事务提交后数据自动清空，干净利落。反之，如果数据需要在多个HTTP请求间复用（例如用户会话级的缓存权限树），才需要考虑ON COMMIT PRESERVE ROWS。
需要特别警惕的是，使用PRESERVE ROWS时数据会存活到连接关闭，而Java应用普遍使用连接池（如HikariCP），连接的复用会导致不同线程可能读到属于上一个会话的旧数据。真实踩坑案例：有人用PRESERVE ROWS的临时表做分页缓存，结果第二页查出了第一页的数据，原因正是连接被池子复用了。
ON COMMIT DELETE ROWS：提交即清空，适合一次性业务流，不会给后续调用留下麻烦。ON COMMIT PRESERVE ROWS：数据保留到连接关闭，但在连接池场景下极易引发数据泄漏。
Java批量插入临时表，避免性能瓶颈
如果使用executeUpdate()逐条插入，处理上万级数据的速度会慢得令人难以接受。临时表虽然减少了redo日志的写入，但每行数据仍然需要走完整的SQL解析、行锁获取和内存分配路径。正确的做法是采用批处理加绑定变量。
可以这样说：
- 正确姿势：使用
PreparedStatement的addBatch()+executeBatch()方式，同时加上INSERT /*+ APPEND */Hint——注意，这个Hint在GTT上只对直接路径插入有效。 - 错误姿势：使用
Statement手动拼接字符串插入，不仅触发硬解析，还容易导致SQL注入。 - 有个细节：Hint
APPEND要求表没有索引，否则会失效。因此如果要插入大量数据，建议先删除索引，插入完成后再重建。
临时表的索引与统计信息，配置不当会翻车
GTT的索引是会话级的私有对象，这一点很多人理解不够到位——索引本身虽然存在，但优化器看到的统计信息默认是空的，它会以为临时表只有一行数据。一旦临时表参与大表的JOIN操作，执行计划几乎一定会选错。
Java层不能寄希望于DBA手动收集统计信息，必须在插入完成后主动触发刷新：
- 插入完成后立即执行一条匿名块：
BEGIN DBMS_STATS.GATHER_TABLE_STATS(ownname=>USER, tabname=>'TMP_CALC_ORDER'); END; - 索引必须在建表时就创建好，不能在Java代码中动态执行
CREATE INDEX——这又回到了权限问题。预先创建好索引，批插入后再查询才能避免全表扫描。 - 千万别轻信“临时表不需要索引”这种说法，一旦后续有
WHERE order_id IN (...)或者JOIN操作，没有索引就是性能灾难。
临时表并非“在应用里随便建个表放中间数据”的捷径。它的生命周期、索引可见性、统计信息更新机制都与Java的连接池行为深度绑定。最容易被忽视的两个风险：一是连接复用下PRESERVE ROWS等于数据泄漏；二是未收集统计信息让优化器彻底“失明”。只有把这些问题处理妥当，临时表才能真正成为高效处理中间数据的利器。
