Java中临时表数据残留的根本原因是连接池复用导致session未真正销毁，而非SQL错误；Oracle临时表数据仅在session结束时清空，连接归还池后仍保持INACTIVE状态，故必须显式TRUNCATE且禁用隐式缓存。
为什么Java里用完临时表数据还在？
根本不是sql写错了，而是连接没真正断开。java调用connection.close()后，如果用的是oracledatasource或带连接池的配置（如c3p0、hikaricp默认oracle驱动），连接只是归还池中，session状态变成inactive而非销毁。而create global temporary table ... on commit preserve rows只在session真正结束时清空数据——下次从池里取到这个连接，就直接看到上次留下的脏数据。
典型现象包括：
- 同一接口反复调用，
SELECT结果行数越查越多 - 报错
ORA-00942: table or view does not exist——其实是连接切换导致临时表定义丢失（尤其c3p0重连时丢session上下文） - 不同线程/用户共用连接池，偶尔读到对方插入的临时表数据（未设
ON COMMIT DELETE ROWS时风险更高）
必须显式TRUNCATE，不能依赖“自动清空”
Oracle临时表不支持DROP TABLE（会报ORA-14452），也不能靠事务提交自动清理——尤其当连接复用但未显式commit时，ON COMMIT DELETE ROWS表里的数据照样残留。唯一可靠做法是每次用完立刻TRUNCATE TABLE。
实操要点：
- 对
ON COMMIT PRESERVE ROWS表：执行TRUNCATE TABLE temp_user_ids（注意别带#前缀，用真实表名） - 对
ON COMMIT DELETE ROWS表：先connection.commit()再TRUNCATE，避免未提交事务残留 - 插入前加
SET TRANSACTION ISOLATION LEVEL READ COMMITTED，防止读到未提交的旧数据
连接池必须关掉隐式连接缓存
OracleDataSource默认开启implicit caching，这是session长期存活的根源。必须显式禁用：
- 代码里设置：
dataSource.setConnectionCacheProperties(false) - 或改用
oracle.jdbc.pool.OracleConnectionPoolDataSource（它天生不带隐式缓存） - 验证是否生效：查
v$session，执行SELECT sid, status, schemaname FROM v$session WHERE username = 'YOUR_SCHEMA'，确认session不再长期卡在INACTIVE状态
索引和批量操作要按需配
临时表虽不写redo，但查询慢一样拖垮性能。关键点不在“临时”，而在“怎么用”：
- 高频
WHERE或JOIN字段必须建索引，比如CREATE INDEX idx_temp_user_id ON temp_user_ids(user_id) - 避免单次插入上万行，用
addBatch()/executeBatch()分批处理（batch size建议100–500） - 不用
SELECT *，只查需要的列；临时表统计信息容易不准，必要时手动DBMS_STATS.DELETE_TABLE_STATS并锁定
临时表本身轻量，但用法错一点，就会把连接池、事务、索引全拖进坑里——问题从来不在表，而在你怎么把它塞进Java的连接生命周期里。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
