股海求生做数据分析和报表开发时，创建临时表是我处理复杂查询的首选手段之一。遇到那种要关联七八张表、中间结果还要反复用到的业务需求，临时表一上，逻辑瞬间清爽，性能也能提升一大截。但我也见过不少同事在临时表上踩坑：有的方法用错导致数据对不上，有的临时表忘记清理，结果把生产库的日志撑爆了。这篇内容把SQL创建临时表的主流方法完整梳理一遍，包括SELECT INTO、CREATE TABLE加INSERT、WITH AS表达式、表变量和全局临时表，结合实际场景讲清楚每种方式的适用边界和操作细节。无论你刚入门还是已经写了一阵子SQL，都值得对照自查一遍。
1. 为什么需要临时表：核心场景与选型思路
1.1 临时表到底解决什么问题
临时表本质上是把一次查询的中间结果持久化到当前会话的临时存储空间中，让后续操作可以反复引用，而不用反复扫描原始大表。最常见的场景有三类。
第一类是复杂报表的分步计算。比如要统计每个客户连续三个月的下单情况，直接写一条SQL可能嵌套五六层子查询，不仅可读性差，执行计划还可能出现严重的预估偏差。合理的做法是先创建临时表存放每个客户每月的汇总数据，再基于临时表做月份连续性判断，每一步都能单独验证。
第二类是减少大表重复扫描。同样一批数据如果在一个SQL里被引用多次，优化器未必能智能地合并扫描。把中间结果先落到临时表，后续所有计算都基于这个已经收敛的数据集，速度往往快很多。
第三类是跨库或跨系统取数。业务数据分布在不同的实例中，某些场景下不能直接做跨库关联，这时候把A库的数据导入临时表，再与B库的表关联，是常见解法。
临时表和普通表的本质差别在于生命周期和作用域。普通表一旦创建就永久存在，谁都能查，删起来还要权限；临时表通常只存在于当前连接或当前会话中，连接关闭后自动消失，不会污染正式表结构，也不会造成长期数据冗余。这是它被高频使用的基础原因。
1.2 选型逻辑：先回答这四个问题
面对一个具体需求，不要上来就无脑SELECT INTO。我一般先问自己四个问题，答案不同选的方案完全不同。
第一个问题：这个中间结果我要用几次？如果只在一个SQL语句内复用，用WITH AS就够了，没必要建真正的临时表；如果后续五六条SQL都要用到，就得建真临时表。
第二个问题：数据量大概多大？几千行的小数据集，表变量和临时表性能差异不大；百万行以上就优先考虑带索引的临时表，表变量这时候容易拖后腿。
第三个问题：生命周期持续多久？只想在当前这个存储过程里用，那就用#开头或者DECLARE TABLE变量的方式；如果希望所有会话都能看到，比如给一批后台作业共享中间结果，就用全局临时表。
第四个问题：是否需要建索引、加约束？SELECT INTO创建临时表无法直接加主键和索引，CREATE TABLE方式则可以完整定义表结构。如果你的临时表后面要频繁关联和筛选，后者是更稳的选择。
这几个问题想清楚，方法基本就定了。接下来逐个拆解每种创建方式。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 几种主流创建临时表方式对比
2.1 SELECT INTO：最快速的临时表生成方式
SELECT INTO是从查询结果直接生成新表的标准语法，SQL Server、MySQL、PostgreSQL都支持。它的最大优势是快和简单，一行代码就把数据结构和数据一股脑带过去了。
在SQL Server中，如果只是想建一个会话级临时表，表名加一个#前缀就行：
sql复制SELECT
customer_id,
MONTH(order_date) AS month_no,
SUM(amount) AS total_amount
INTO #month_summary
FROM orders
WHERE order_date >= '2024-01-01'
GROUP BY customer_id, MONTH(order_date);
执行完之后，当前会话里就多了一个#month_summary临时表，后续任何SQL都可以直接查询它。
在MySQL里写法略有不同，使用CREATE TEMPORARY TABLE加SELECT：
sql复制CREATE TEMPORARY TABLE temp_month_summary AS
SELECT
customer_id,
MONTH(order_date) AS month_no,
SUM(amount) AS total_amount
FROM orders
WHERE order_date >= '2024-01-01'
GROUP BY customer_id, MONTH(order_date);
PostgreSQL的写法是CREATE TEMP TABLE加AS SELECT，Oracle则是CREATE GLOBAL T