DB2临时表创建那些事儿，别忘了这些细节和注意点

DB2中的临时表是个非常有用的功能,特别是在处理复杂计算、数据暂存或会话隔离数据的场景下，但用得好不好，全看细节把握得牢不牢，咱们就聊聊创建DB2临时表时那些容易忽略的细节和必须注意的点。

最核心的一点是分清两种临时表：已声明的临时表 和创建的临时表，这是两个完全不同的东西，用混了会出大问题。

已声明的临时表，顾名思义，是用 DECLARE GLOBAL TEMPORARY TABLE 语句来定义的，这种表的存在感非常“临时”，它只在当前会话的生命周期内有效，一旦你断开与数据库的连接，这个表以及里面的数据就会自动消失，像从来没存在过一样，根据DB2官方手册的描述，这种表的数据不会记录在日志中，因此操作起来速度非常快，对性能影响小，它存储在临时表空间里，不会与普通用户表产生冲突，需要注意的是，你必须在语句中明确指定表的列定义，它不能像普通表那样通过 LIKE 或 AS 子句从其他表复制结构（不过有些DB2版本支持 LIKE 选项），这种表最适合在存储过程、函数或复杂的批处理脚本中，作为中间结果集的计算载体。

创建的临时表，则是使用 CREATE GLOBAL TEMPORARY TABLE 语句，这个名字听起来和“已声明的”很像，但行为天差地别，这种表的结构是持久化的，也就是说，你创建一次之后，它的定义就永久存储在系统目录中，所有有权限的用户都能看到这个表定义。表中的数据依然是临时的，每个向这个表插入数据的会话，都只能看到和操作自己塞进去的数据，其他会话的数据对它来说是透明的，数据同样会在会话结束时被自动清空，根据DB2信息中心的技术说明，这种表适用于需要多个会话共享同一个表结构，但数据必须相互隔离的场景。

选择哪种？关键在于你对表结构的需求，如果这个临时表的结构只是当前这个程序或会话临时用一下，以后大概率用不上，就用 DECLARE，省事干净，如果这个表结构（比如一个标准的数据处理模板）会被多个程序或会话反复使用，那么就应该 CREATE 一个全局临时表的定义，一劳永逸。

接下来是几个无论哪种临时表都需要特别注意的细节：

事务提交的影响 这是最容易栽跟头的地方，临时表的行为可以通过 ON COMMIT 子句来控制，你可以在创建或声明时指定：

• ON COMMIT DELETE ROWS：这是默认选项，意思是，每当执行 COMMIT（提交）操作时，临时表里的所有数据都会被自动清空，如果你在一个事务里先插数据，然后做查询，中间一旦提交了，再查表就是空的了，这对于需要跨事务保持数据的场景是致命的。
• ON COMMIT PRESERVE ROWS：指定这个选项后，即使执行了提交操作，临时表里的数据也会被保留下来，直到会话结束，如果你需要在一个会话内进行多次提交，但又不想丢失临时数据，就必须记得加上这个子句。

日志记录与性能 正如IBM知识库文档所指出的，已声明的临时表通常不记录日志（除非你定义了索引或触发了某些特定操作），这是它高性能的主要原因，但也意味着，如果系统发生故障，这些临时数据是无法恢复的，不过反正也是临时的，丢了也无所谓，而创建的临时表，其数据操作通常是有日志记录的，但这部分日志记录量可以被优化，理解这一点有助于在追求极致性能和保证可恢复性之间做权衡。

索引的使用 临时表也是可以创建索引的，特别是对大型的中间结果集，创建合适的索引能极大提升后续查询的速度，给已声明的临时表加索引，必须在声明表的同一个复合语句中完成（在存储过程里，DECLARE 表之后紧接着 CREATE INDEX），你不能在后续的SQL语句中单独为它创建索引，而对于创建的临时表，索引是随着表定义一起持久化的，所有会话共享这个索引定义，但索引中的数据依然是会话隔离的。

权限问题 对于已声明的临时表，因为它只是当前会话的私有对象，所以通常不需要额外的权限（只要你有权使用临时表空间），但对于创建的临时表，由于它的定义是全局的、持久的，你就需要有 CREATE TABLE 的系统权限才能创建它，其他用户要想使用这个已创建好的临时表结构，可能需要被授予相应的 REFERENCES 或 INSERT 等权限。

使用时机 不要滥用临时表，如果可以通过一个复杂的SQL查询搞定，或者使用公共表表达式（CTE）就能解决问题，那么引入临时表反而会增加代码的复杂度和维护成本，临时表的优势在于它能“物化”中间结果，避免重复计算，或者在多步处理中简化逻辑，当单条SQL语句变得过于复杂和难以阅读时，就是考虑使用临时表的好时机。

DB2临时表是个强大的工具,但“魔鬼在细节中”，务必在动手前想清楚：我需要哪种临时表（声明还是创建）？我的数据需要存活多久（受提交影响吗）？需不需要索引来加速？想明白了这些，你才能得心应手地使用它，避免掉进坑里。