Java高效利用Oracle临时表处理海量中间业务数据

先说几个核心结论：在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注入。
• 有个细节：HintAPPEND要求表没有索引，否则直接失效。所以如果要插入大量数据，先删索引，插完再重建。

临时表的索引和统计信息，配不好就翻车

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等于数据泄漏；二是未收集统计信息让优化器彻底“失明”。把它们处理好了，临时表才能真正成为高效处理中间数据的利器。