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