Pinxian Li做数据的人，跟临时表打交道基本是家常便饭。不管是写存储过程、做报表、处理中间结果集，还是排查一条慢SQL，临时表都算得上是最趁手的工具之一。很多时候你发现一条SQL写得又臭又长、一堆子查询嵌套得看不出人样，换个思路用临时表拆几步，逻辑立刻清爽，执行效率也往往能上来。所以我一直觉得，临时表不是啥高深技术，但用得好不好，直接反映一个人写SQL的基本功扎不扎实。
这篇就专门把“创建临时表”这件事掰开揉碎讲清楚。我会用自己的实操习惯来讲，包括什么时候用临时表、几种创建方式的差异、作用域和生命周期这些最容易踩坑的细节，最后附上我用临时表解决真实业务问题的完整思路。内容以SQL Server为主，其他数据库的差异我也会点一下，因为很多理念是通用的。
1. 临时表的核心机制与适用场景
1.1 临时表到底是什么，它存在哪里
先弄清楚临时表的本质。临时表在SQL Server里是存在tempdb系统数据库里的，而不是你当前所在的业务数据库。这意味着你创建临时表，实际是在往tempdb里写数据。tempdb的特点是：实例每次重启都会被清空重建，临时表也会随之消失。这个机制决定了临时表天生适合存放“当前会话、当前任务需要的中间数据”，不适合放需要长期留存的数据。
不同数据库叫法不一样，SQL Server里临时表名字前面带#或##，比如#tempOrders。MySQL里则是CREATE TEMPORARY TABLE，效果类似，连接断开表自动消失。Oracle里有全局临时表GLOBAL TEMPORARY TABLE，定义是永久的，但数据是会话级或事务级的。概念上大家说的都是同一件事：给你一块临时的工作区域，用完自动清理。
我自己习惯把临时表理解成“草稿纸”。正式报表是写在文档里的最终结果，而中间算来算去的过程，就在草稿纸上完成。草稿纸的好处是你随便画、随便改，不会污染正式数据，也不需要小心翼翼地建一堆正式表来存中间结果。用完一扔，干干净净。
1.2 什么场景下该用临时表
这是新手最常问的问题：我一条SQL能搞定的事，为啥非要建临时表？我的判断标准很简单，出现下面几种情况之一，就该考虑临时表：
- 一个复杂查询里，同一个子查询结果要被引用多次。比如你先算出一批符合条件的用户ID，后面要跟订单表、跟行为日志表、跟用户信息表关联好几次，那这段用户ID集合就非常值得抽出来放临时表。
- 查询层次太深，嵌套子查询超过三四层，自己都绕晕了。拆成临时表之后，每个步骤都能单独验证、单独调试，排查问题容易得多。
- 需要对中间结果做多次不同维度的聚合。比如先算出每笔订单的成本和收入明细，再分别按天、按分类、按渠道汇总，一份明细临时表就够全复用。
- 要处理的数据量比较大，而且后续要做复杂的过滤、排序、分页。把需要的数据先圈进临时表，后续操作都在小结果集上进行，比反复扫描大表快很多。
- 在存储过程里需要在循环中逐步处理数据，或者需要分层迭代计算，临时表几乎是必须的。
反过来，如果查询本身只有一层、逻辑不复杂，那没必要硬凑临时表。临时表是有开销的——要写tempdb，要分配空间，要记录日志。杀鸡不用牛刀，简单的查询直接写就是了。我看到过有人连SELECT * FROM Table1 WHERE Id = 1都要先塞进临时表再查一遍，这就属于把好工具用歪了。
1.3 临时表相比CTE和表变量的优势
现在很多人写复杂查询喜欢用CTE（公用表表达式），写法确实比嵌套子查询清爽不少。但CTE有个天然限制：它本质是个内联视图，大多数情况下不会被物化，意味着你在CTE里写的过滤条件，实际执行时会被下推到后面的查询里。这是好事也是坏事——好事是优化器有机会做更多优化，坏事是如果同一个CTE被引用多次，它可能被重复计算多次，性能反而恶化。
临时表不一样，它当场就物化，数据实打实落盘。后续不管你引用多少次、怎么关联，读的都是这一份已经算好的结果。这对那种“先做重活、再反复轻量使用”的场景特别友好。
至于表变量，很多人拿它当临时表的替代品。表变量在内存里（或者溢出到磁盘），看起来更轻量，但有两个硬伤：一是表变量没有统计信息，优化器不知道里面有多少行数据，数据量大时容易选错执行计划；二是表变量不能建索引（除非用内联索引声明），数据稍微多一点查询性能就很拉胯。我的经验是：数据量小（比如几百行以内）用表变量确实方便，代码干净；数据量一大，或者要反复关联过滤，老老实实用临时表，别跟性能过不去。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 创建临时表的几种方式与选择逻辑
2.1 方式一：用SELECT INTO直接创建并写入
这是我最常用、也最推荐的一种方式。语法极其简单：
sql复制SELECT
OrderId,
CustomerId,
SUM(Amount) AS TotalAmount
INTO #OrderSummary
FROM Orders
GROUP BY OrderId, CustomerId;
这条语句执行完，#OrderSummary这个临时表就被自动创建出来了，列的结构和数据类型完全来自SELECT查询的结果。不需要预先写CREATE TABLE语句，不需要手工定义每一列的长度和精度，省事到没朋友。
SELECT INTO的关键优势是，它不需要你事先设计表结构。而且它的日志记录方式是批量操作，数据量大了之后写入速度非常可观。我在做报表数据预处理时，经常用它把几千万行明细压成几十万行汇总，整个过程非常快。
不过要小心几个坑。第一，它会自动推断数据类型，但推断规则不一定符合你的需求。比如原表里某列是NVARCHAR(MAX)，你SELECT了一个子串出来，目标列可能就被推断成NVARCHAR(MAX)了，后续建索引会有麻烦。我习惯在SELECT里就用CAST或CONVERT把类型显式固定下来。第二，SELECT INTO不会自动创建主键、索引、默认值、约束这些东西，如果你后续要按某列频繁查询，需要另外建索引。
如果你想通过SELECT INTO在临时表里加一个自增ID列，可以用IDENTITY函数：
sql复制SELECT
IDENTITY(INT, 1, 1) AS RowId,
OrderId,
CustomerId
INTO #TempWithRowId
FROM Orders;
这样临时表里第一列就变成从1开始的自增编号了，在需要按顺序处理数据的场景下很好用。
2.2 方式二：用CREATE TABLE定义结构再写入
有些场景你必须先定义好表结构再填充数据。典型情况是：你需要精确控制列的数据类型，设置主键，加默认值，或者临时表里有些列无法通过一个简单的SELECT直接算出来，需要后面分步骤更新。这时候就用标准写法：
sql复制CREATE TABLE #TempUserScore
(
UserId INT PRIMARY KEY,
UserName NVARCHAR(50),
Score DECIMAL(10, 2) DEFAULT 0,
Grade VARCHAR(10) NULL
);
INSERT INTO #TempUserScore (UserId, UserName, Score)
SELECT UserId, UserName, Score
FROM Users
WHERE Status = 1;
先建表、再插入，好处是结构完全可控。比如你明确