Oracle临时表在连接池中残留数据的根本原因是连接未真正断开，session保持INACTIVE状态导致ON COMMIT PRESERVE ROWS临时表不清空；必须显式TRUNCATE并禁用隐式连接缓存。
oracle临时表在连接池环境下极易残留数据、引发冲突，根本原因不是sql写得不对，而是连接没真正断开——session还活着，临时表就还在。
为什么close()后临时表数据还在？
Java调用connection.close()时，如果用的是OracleDataSource（尤其带连接池），实际只是把连接归还池中，session状态变为INACTIVE而非销毁。Oracle的会话级临时表（CREATE GLOBAL TEMPORARY TABLE ... ON COMMIT PRESERVE ROWS）只在session真正结束时才清空数据，所以下次从池里取到这个连接，会看到上次留下的脏数据。
常见现象包括：
- 同一接口反复调用，查询结果越来越多（实际是叠加了前几次插入的临时表数据）
- 报错
ORA-00942: table or view does not exist——不是真不存在，而是连接切换导致临时表定义丢失（某些连接池如c3p0会重连并丢弃session上下文） - 不同用户/线程共用连接池，互相看到对方临时表里的数据（极少见但可能，尤其未设
ON COMMIT DELETE ROWS）
必须显式清理：TRUNCATE + SET TRANSACTION
不能依赖“自动清空”，必须在每次使用后主动干预。关键不是删表，而是清空+重置会话状态：
- 对
ON COMMIT PRESERVE ROWS临时表：执行TRUNCATE TABLE #temp_name（注意Oracle不支持#前缀，应为真实名如TEMP_USER_IDS） - 对
ON COMMIT DELETE ROWS临时表：虽理论上事务提交即清空，但若连接复用且未显式COMMIT，数据仍残留；建议统一加connection.commit()后再TRUNCATE - 更稳妥做法：在插入前加
SET TRANSACTION ISOLATION LEVEL READ COMMITTED，避免读到未提交的旧残留 - 不要用
DROP TABLE——临时表定义属于session，drop会报ORA-14452（attempt to create, alter or drop an index on temporary table already in use）
连接池配置必须关掉隐式连接缓存
OracleDataSource默认开启隐式连接缓存（implicit caching），这是session不销毁的元凶。必须显式禁用：
立即学习“Java免费学习笔记（深入）”；
- 代码中设置：
dataSource.setConnectionCacheProperties(false) - 或改用
oracle.jdbc.pool.OracleConnectionPoolDataSource（它不带隐式缓存） - 对比验证：用
SELECT sid, status, schemaname FROM v$session WHERE username = 'YOUR_SCHEMA'查session状态，正常关闭后应消失；若长期INACTIVE，说明缓存未关 - 慎用OCI驱动：虽然OCI下
close()真销毁session，但它依赖本地Oracle客户端，部署复杂、跨平台差，不推荐生产环境替换thin驱动来解这个问题
临时表命名与生命周期要绑定业务上下文
靠名字防冲突不靠谱，但可降低误操作风险：
- 命名带上线程ID或请求ID：
TEMP_USER_IDS_12345，避免多个请求复用连接时覆盖 - 不用
CREATE GLOBAL TEMPORARY TABLE建新表，而是在应用启动时一次性建好（如TEMP_BATCH_IDS），只做INSERT/TRUNCATE - 如果必须动态建表，确保
DROP语句放在finally块里，并捕获ORA-00942忽略（因为表可能已被其他连接删过） - 绝对不要在存储过程中创建临时表再返回给Java——Oracle PL/SQL里建的临时表，其生命周期受调用session控制，Java端无法干预
最易被忽略的一点：TRUNCATE本身是个DDL操作，会隐式触发COMMIT，如果你的业务逻辑依赖事务回滚，它会提前切断事务边界。需要把临时表操作和主业务拆成两个独立事务，或者改用DELETE FROM ... WHERE 1=1（性能稍差但可控）。
