说说Oracle临时表那些用着顺手又容易踩坑的经验和体会

开头先说说为啥觉得它顺手。

最顺手的地方,就是它能“各管各的”。（来源：Oracle官方文档关于临时表会话独立性的描述）我记得有个报表功能，数据需要经过七八步非常复杂的计算和筛选，中间会产生大量的临时数据，如果放在普通表里，多个用户同时跑这个报表，他们的中间数据肯定会混在一起，乱成一锅粥，但用了临时表之后，每个用户登录进来，看到的就是自己会话的那份数据，就像进了自己的私人房间，里面的东西别人动不了，自己也碰不到别人的，这种会话级别的隔离性，做复杂业务逻辑或者报表时，心里特别踏实，根本不用担心并发冲突。

第二个顺手点是“自动清空，省心省力”。（来源：基于事务或会话的删除特性）临时表有两种，一种是事务级别的，事务一提交，数据就没了；另一种是会话级别的，你断开数据库连接，数据才清空，这太方便了，比如我做一个数据导入的校验，需要把文件数据先暂存起来，然后逐条检查，我用事务级别的临时表，如果中途发现错误，我直接回滚事务，不仅操作撤销了，临时表里的脏数据也自动消失了，不用我手动去DELETE，避免了忘记清理导致表越来越臃肿的问题，这种“用完即焚”的特性，减少了大量维护代码。

第三个是“性能上的甜头”。（来源：临时表产生重做日志Redo极少的特点）临时表的数据操作，基本上不产生或者只产生极少量的重做日志（Redo Log），重做日志是为了保证数据库崩溃后能恢复的，但写日志本身是很大的性能开销，对于中间计算这种“丢了就丢了，再算一遍就好”的数据，没必要那么严格保护，当我把一些原本在普通表上进行的、会产生海量日志的中间步骤移到临时表后，速度提升非常明显，对数据库整体的I/O压力也小了很多。

顺手的东西用不好，坑也来得特别快。

我踩的第一个大坑就是“创建表的时机”。（来源：实际开发中的常见误区）刚开始不懂，我在一个存储过程里，直接写CREATE GLOBAL TEMPORARY TABLE ...，第一次执行没问题，第二次执行就报错了，说“表已存在”，我才明白，临时表的结构（表定义）是永久的，只是在首次使用前，数据区是空的，所以正确的做法是，在应用部署初始化的时候，就一次性把临时表创建好，在存储过程或代码里，直接INSERT或SELECT就行，千万别在频繁执行的程序里包含CREATE TABLE语句，否则肯定报错。

第二个坑是“统计信息的陷阱”。（来源：Oracle优化器对空表处理的经验）临时表在没人用时是空的，Oracle的优化器在生成执行计划时，会依赖表的统计信息，但一个长期为空的表，统计信息可能显示它只有0条记录或很少记录，当你关联查询时，优化器可能会认为这是个小表，错误地选择了嵌套循环连接（Nested Loop）而不是更高效的哈希连接（Hash Join），因为实际运行时你的临时表里可能有几百万条数据，这就导致执行计划不准，SQL性能急剧下降，我的经验是，要么在临时表刚创建完、还是空表的时候，就手动收集一下统计信息（但这样可能也不准）；更好的办法是在SQL中使用DYNAMIC_SAMPLING提示，或者更彻底地在会话级别设置OPTIMIZER_DYNAMIC_SAMPLING到一个较高的级别（比如4），强制优化器在解析时动态采样临时表的数据量，这样生成的计划就靠谱多了。

第三个容易忽略的坑是“空间占用”。（来源：临时表空间管理机制）虽然临时表不产生多少Redo，但它使用的空间是在临时表空间（TEMP Tablespace）里分配的，如果你的SQL写得不好，比如在临时表上做了大量排序、哈希操作，或者一次性往临时表里塞了超大的数据量，就会疯狂占用临时表空间，更可怕的是，如果一个会话异常终止，Oracle可能不会立即释放它占用的临时段，导致临时表空间被“撑爆”，影响整个数据库所有需要用到临时空间的操作（比如排序、分组），要时刻监控临时表空间的使用情况，优化SQL，避免在临时表上做不必要的复杂运算。

第四个坑算是“设计思路的坑”。（来源：对临时表适用场景的反思）不是所有临时数据都适合扔给临时表，一个简单的子查询或者WITH子句（CTE）就能搞定的事情，为了“图省事”而启用临时表，反而是杀鸡用牛刀，因为访问临时表也是有开销的，临时表更适合的是那种中间结果集很大、需要被多次频繁访问、或者计算步骤确实非常复杂的场景，如果只是用一次的小结果，用CTE可能性能更好，代码也更清晰，用之前得想清楚，是不是真的有必要。

Oracle临时表是个强大的工具,它的会话隔离和自动清理机制用起来非常顺手，性能优势也明显，但要想用好，必须避开几个关键坑：永久创建，一次搞定；小心统计信息，防止执行计划出错；关注临时表空间，别让它成为瓶颈；根据场景选择，别滥用。 把这些经验和体会记牢，临时表才能真正成为你手里的神兵利器，而不是性能炸弹。