是否所有使用临时表的SQL查询都可改写为纯集合查询？

核心结论：理论上可行，但实际需结合场景权衡 #

• 从关系代数的底层逻辑来看，临时表本质是把分步的集合操作拆解后暂存结果，每一步的临时表逻辑都可以用子查询、CTE（公共表表达式）、JOIN等纯集合操作替代。比如你先创建临时表A、再基于A生成临时表B，最终查询B的逻辑，完全可以把A的定义嵌套成子查询放到B的语句里，或者用WITH子句依次定义A和B的逻辑，最终合并成一个纯集合查询。
• 但实际场景中，存在没必要强行转换的情况：
  • 当业务逻辑复杂度极高时，纯集合查询会变得冗长晦涩，可读性和后续维护成本直线上升，这时用临时表拆解成小模块反而更合理。
  • 部分数据库对复杂嵌套子查询的优化能力有限，临时表可以通过添加索引、更新统计信息来提升执行效率，实际跑起来可能比纯集合查询更快。
• 还有一类特殊场景：如果临时表中包含非集合类逻辑（比如循环插入数据、依赖前一行结果的逐行计算，类似游标逻辑），这类情况转纯集合查询的成本极高，可能需要借助窗口函数、递归CTE等数据库特定语法才能模拟，甚至部分小众数据库不支持这类复杂语法。

总结 #

不是所有使用临时表的场景都适合改写成纯集合查询，需要在可读性、维护性、执行效率之间做取舍。如果只是用临时表拆解集合类逻辑，理论上都能转换；但涉及非集合的逐行操作，转换难度会很大，甚至需要依赖数据库的特定功能支持。

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