分多步使用临时表的SQL编写风格是否有专属术语及DB2写法溯源

两类写法的正式专业术语 #

• 你日常使用的、通过CTE、派生表、子查询将业务逻辑整合在少量语句内实现的写法，正式名称为集合式SQL（Set-based SQL），属于SQL标准推荐的范式，核心是将数据处理抽象为集合间的运算，由数据库优化器统一生成最优执行计划，迭代修改、维护的效率更高。
• 存量代码中拆分为大量步骤、使用QTEMP临时表逐段存储中间结果、通过ALTER/UPDATE逐次加工数据的写法，正式名称为过程式分步SQL（Procedural Step-by-step SQL），在传统DB2开发者圈子里也常被称为临时表流水式写法，本质是用过程化编程的思路编写SQL，把完整的集合运算拆成多步串行的离散操作。

该写法在DB2生态广泛留存的原因 #

• 早期版本功能限制：DB2 for i（原AS/400平台DB2）直到2006年发布的V5R4版本才正式支持CTE语法，派生表、关联子查询的稳定优化支持直到2008年的V6R1版本才落地，更早版本中编写复杂嵌套SQL要么直接报语法错误，要么优化器会生成执行效率极差的计划，性能远低于拆临时表分步执行的方案，老开发者的编码习惯就是在这个阶段形成的，后续数据库升级后习惯也没有同步调整。
• 早年调试成本过高：早期DB2没有可视化执行计划、没有完善的语句级调试工具，拆分为多步临时表的写法可以在每一步执行完成后直接查询临时表校验中间结果，排查数据问题的门槛远低于嵌套的集合式SQL，对非DBA背景的业务侧开发非常友好。
• 旧版本优化器缺陷：即使在CTE、子查询语法上线后的很长一段时间里，DB2优化器对复杂嵌套查询的基数估算偏差很大，经常出现选错关联方式、索引命中异常、内存溢出等问题，老开发者经过大量踩坑形成了“拆临时表比写嵌套语句稳定”的经验，这类经验在开发团队内代际传递，就导致新版本已经修复优化器问题后，旧写法依然被广泛使用。

改造相关说明 #

你提到的简单3表关联场景的旧写法是典型的过程式分步SQL，示例代码如下：

Create qtemp.cust as (  
Select
CustNo,
CustName
From Customer)
;
Alter Table qtemp.cust
add Column Revenue
;
Update Table qtemp.cust A
Set Revenue = (select sum(revenue) from Sales B Where A.CustNo = B.CustNo)
;
Insert into F_SALES
Select * from qtemp.cust

这类代码改造成本高的核心原因并非逻辑复杂，而是多数旧脚本的中间步骤没有配套注释，逐段加工临时表的过程中往往隐含了特殊数据过滤、异常值修正等零散业务规则，重构时需要逐段校验逻辑等价性，避免遗漏规则导致最终数据错误。你提到的将56步旧脚本重构为2步、获得76%性能提升的效果，正是集合式SQL配合新版DB2优化器的典型优势。

内容的提问来源于stack exchange，提问作者Mike Seisbye