SQL Server临时表创建全攻略：从SELECT INTO到作用域与性能实战

做数据的人，跟临时表打交道基本是家常便饭。不管是写存储过程、做报表、处理中间结果集，还是排查一条慢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被引用多次，它可能被重复计算多次，性能反而恶化。

临时表不一样，它当场就物化，数据实打实落盘。后续不管你引用多少次、怎么关联，读的都是这一份已经算好的结果。这对那种“先做重活、再反复轻量使用”的场景特别友好。

至于表变量，很多人拿它当临时表的替代品。表变量在内存里（或者溢出到磁盘），看起来更轻量，但有两个硬伤：一是表变量没有统计信息，优化器不知道里面有多少行数据，数据量大时容易选错执行计划；二是表变量不能建索引（除非用内联索引声明），数据稍微多一点查询性能就很拉胯。我的经验是：数据量小（比如几百行以内）用表变量确实方便，代码干净；数据量一大，或者要反复关联过滤，老老实实用临时表，别跟性能过不去。

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;

先建表、再插入，好处是结构完全可控。比如你明确知道用户名最长30个字符，那字段就定义成NVARCHAR(30)，而不是让SQL Server帮你推断成一个可能过大的类型。有些公司对临时表的字段类型和长度有统一规范，因为没准临时表里的数据后面还要移到正式表里去，字段类型不一致容易出现转换问题。

这种方式特别适合“多次插入+后续更新”的套路。临时表结构先建好，你可以在一个存储过程里分阶段往里面INSERT数据，中间再UPDATE修正某些列的值。整个数据加工过程流水线化，每一步都清晰可见。

建表的时候，主键和索引设计好，对于后续的查询性能影响非常大。数据量几万行以内可能无所谓，一旦到了几百万行，没有主键和索引的临时表做关联查询，那速度会让你怀疑人生。

2.3 其他数据库怎么创建临时表

MySQL里创建临时表的方式跟SQL Server有相似也有差异。基本语法：

sql复制CREATE TEMPORARY TABLE temp_user_score (
    user_id INT PRIMARY KEY,
    user_name VARCHAR(50),
    score DECIMAL(10,2)
) ENGINE = InnoDB;

MySQL同样支持CREATE TEMPORARY TABLE AS SELECT来直接建表并写入，类似SQL Server的SELECT INTO，但写法略有不同。由于MySQL的临时表只对当前会话可见，且连接结束自动销毁，所以不用担心多个会话之间互相干扰。注意一点：MySQL里临时表可以和正式表同名，且同名的临时表会优先被访问。这有时是故意的，有时会带来隐患，比如你建了个临时表跟业务表同名，忘了删，后续代码全读到了临时表上。我建议命名上统一加前缀，比如tmp_，避免这种尴尬。

PostgreSQL也支持临时表：

sql复制CREATE TEMPORARY TABLE temp_user_score (
    user_id INTEGER PRIMARY KEY,
    user_name TEXT,
    score NUMERIC(10,2)
) ON COMMIT DROP;

ON COMMIT DROP表示事务结束就自动删除，这个特性在做事务内中间态计算时很实用。PostgreSQL同样有CREATE TEMPORARY TABLE AS语法，相当于SELECT INTO的变体。

Oracle的全局临时表是基于“定义永久、数据临时”的理念，这是和其他数据库最大不同的地方。你先创建一张全局临时表，它永久存在于数据库中，但每个会话插入的数据只能自己看到。虽然刚开始有点绕，但它的好处是会话之间数据隔离彻底，高并发场景非常安全。

2.4 到底该用哪种方式创建

我自己判断的逻辑非常朴素：数据源是现成的、结构也不需要改，直接用SELECT INTO，能少写一半代码；数据结构要定制、要加主键索引默认值、要多次分步填充，用CREATE TABLE加INSERT；如果只是过程内的一个小中间集，几百行数据，表变量就够了，连临时表都可以省。

一句话总结就是：怎么省事怎么来，同时考虑清楚后续要拿这个表干什么。如果后续只是SELECT读一遍，SELECT INTO够了。如果后续要UPDATE、DELETE、反复关联，建议建表时直接上好主键和索引。这个决策过程熟练之后，几乎就是下意识反应。

3. 作用域、生命周期与自动清理机制

3.1 本地临时表和全局临时表的区别

创建临时表时，名字前面的#号数量是有讲究的。一个#开头，比如#MyTemp，是本地临时表，只对创建它的会话可见。另一个会话里就算执行完全一样的代码也看不到它，更不可能访问到。

两个##开头，比如##MyTemp，是全局临时表，对所有会话都可见，谁都能读谁都能写。但全局临时表有个很微妙的生命周期规则：只要创建它的会话还活着，全局临时表就存在；一旦创建会话断开，它就会被销毁，前提是没有其他会话正在引用它。

理解这个机制，可以避免一个很经典的生产事故：在存储过程或长时间运行的会话里创建了全局临时表，如果代码没处理好，或者会话异常断开不干净，全局临时表可能残留在tempdb里，别人想建同名的就报错。我一直建议能用本地临时表就不要用全局的，除非你真的需要跨会话共享中间数据。

会话断开自动清理是临时表的优点，但也意味着你不能指望临时表跨会话留存。比如你把数据算好放临时表里，然后应用层连接池断开了连接，下次再拿一个连接，刚才的临时表已经没了。实际开发中经常遇到“我这临时表明明建了，怎么过一会儿就没了”的疑问，其实多半是会话被连接池回收重建了。

3.2 临时表什么时候会被自动删除

自动删除的触发条件有几个，你需要心里有数：

• 创建临时表的会话（连接）关闭时，所有本地临时表都会自动删除。
• 如果临时表是在存储过程中创建的，存储过程执行完毕后，SQL Server会自动删除这个过程中创建的本地临时表。当然有个例外：如果这个存储过程调用了另一个存储过程，或者触发了嵌套调用，那么临时表在子过程里也能看到，直到最外层过程结束才真正被清掉。
• 如果是全局临时表，当最后一个使用它的会话结束后才删除。这意味着创建者断开后，如果有其他会话还在用，表不会立即消失，等最后一个会话断开才清理。
• 显式执行DROP TABLE #TempName会立刻删除，这也是主动释放tempdb空间的好习惯。

实际操作里，我只要临时表用完了，就主动加句DROP TABLE，不等着系统自动清理。原因在于：存储过程执行完确实会清理，但如果你的会话是长连接，后续还要执行大量其他SQL，那临时表一直占着tempdb空间和资源，对整体性能不友好。主动清理是一种好习惯，尤其在做批量任务时，跑完一批清一批，tempdb的负担会小很多。

3.3 tempdb是共享资源，别当垃圾场

你可能没想过，一个SQL Server实例上所有的临时表、表变量、排序操作、哈希连接的中间结果，全部都要用tempdb。它是个全局共享库，不是只有你一个人在用。

曾经我处理过一个慢SQL问题：一个存储过程每次运行都创建一堆超大临时表，而临时表里的数据全是几百万行的明细数据，处理完也不主动清理。高并发的时候，几个会话同时这么跑，tempdb直接被撑爆，整个实例上的查询集体变慢，连不相关的业务都受影响。

所以我的经验是：临时表里只放必要的数据，不要图省事把一整张大表无脑SELECT * INTO。数据到临时表之前先处理好，能聚合的先聚合，能过滤的先过滤。这既是为了你自己的查询性能，也是别把公共的tempdb资源浪费掉。

3.4 动态SQL里临时表的作用域坑

这个坑非常隐蔽，值得单独拿出来讲。如果你在存储过程里用动态SQL拼接，比如：

sql复制EXEC('SELECT * INTO #temp FROM Orders; SELECT * FROM #temp;');

这里面的#temp只在动态SQL执行的子会话里有效，一出动态SQL，#temp就不可见了。如果你以为存储过程后续还能继续用这个临时表，那就大错特错了，你会得到“对象名无效”的错误。

常见的解决方案有两种。一种是改用全局临时表##temp，因为全局临时表跨会话可见，动态SQL里创建的全局临时表在外部也能访问。但要注意清理时机，不然后患无穷。另一种思路是先把临时表在存储过程外层建好，动态SQL里只做插入操作。这样表是外层会话的本地临时表，动态SQL虽然在不同作用域，但插入操作不涉及访问不存在的表对象，仍然能正常执行。后一种做法我更推荐，既安全又清晰。

4. 实操演示：一个完整的分步骤数据处理过程

4.1 业务场景描述

下面我模拟一个近似的业务场景：假设我有一张用户订单表Orders，里面有近一年上亿条订单记录。运营需要一份“每个用户每个月下单金额、下单次数、以及对应月份的排名”，而且要根据用户所在城市做过滤，最后只输出重点城市用户的汇总结果。如果直接在Orders上一条大SQL写完，连接条件、子查询、聚合层层叠加，SQL Server的执行计划会非常有压力，而且哪怕SQL跑通了，后续加条件改需求也非常痛苦。

我选择分几个临时表把过程拆解开，每一层都有明确职责，跑起来也容易验证。

4.2 第一步：先把数据圈到临时表

先做第一层数据圈选。业务上重点是最近12个月、部分重点城市的订单，我先把这部分窄表数据落到临时表：

sql复制IF OBJECT_ID('tempdb..#OrderBase') IS NOT NULL
    DROP TABLE #OrderBase;

SELECT
    o.OrderId,
    o.UserId,
    o.OrderDate,
    o.CityId,
    o.Amount
INTO #OrderBase
FROM dbo.Orders AS o
WHERE o.OrderDate >= DATEADD(YEAR, -1, GETDATE())
  AND o.CityId IN (1001, 1002, 1003, 1004)
  AND o.Status = 'Completed';

这一层把数据从几亿行直接压到可能只有几百万行甚至更少，后续所有操作都在#OrderBase上进行，扫描代价大幅降低。这里用SELECT INTO，因为查询所返回的每一列数据结构和原表一致，不需要额外定制，省时省力。

写完之后我一般马上跑一条快速验证：

sql复制SELECT COUNT(*) AS RowCount, COUNT(DISTINCT UserId) AS UserCount
FROM #OrderBase;

这一步看起来简单但非常值得做。数据量上万和上千万，后续方案的复杂度完全是两回事。确认圈选结果没问题，再往下一步走。

4.3 第二步：建月份维度的汇总临时表

接下来要做用户月度汇总。为了能让后面的查询快速关联，我只对最终要展示的几个维度做聚合：

sql复制CREATE TABLE #UserMonthlySummary
(
    UserId       INT NOT NULL,
    MonthStart   DATE NOT NULL,
    MonthOrderCount INT NOT NULL,
    MonthTotalAmount DECIMAL(18,2) NOT NULL,
    PRIMARY KEY (UserId, MonthStart)
);

INSERT INTO #UserMonthlySummary (UserId, MonthStart, MonthOrderCount, MonthTotalAmount)
SELECT
    UserId,
    DATEFROMPARTS(YEAR(OrderDate), MONTH(OrderDate), 1) AS MonthStart,
    COUNT(OrderId) AS MonthOrderCount,
    SUM(Amount) AS MonthTotalAmount
FROM #OrderBase
GROUP BY UserId, DATEFROMPARTS(YEAR(OrderDate), MONTH(OrderDate), 1);

这里我用的是CREATE TABLE加INSERT而不是SELECT INTO，原因有两个：加联合主键(UserId, MonthStart)，避免同一个人同一个月重复汇总；后续月粒度排名需要按这个主键做关联，结构清晰、查询高效。如果你用SELECT INTO，这两个特性都不会自动带过来。

DATEFROMPARTS是我很喜欢的函数，直接把年、月拼成当月1号的日期，后续按月份排序、分组都非常方便。

4.4 第三步：用窗口函数加排名

现在对#UserMonthlySummary里的数据做排名。假如我要的是每个用户自己历史的月份排名，或者每个月里用户金额排名，都可在这里一步搞定：

sql复制SELECT
    UserId,
    MonthStart,
    MonthOrderCount,
    MonthTotalAmount,
    RANK() OVER (PARTITION BY UserId ORDER BY MonthTotalAmount DESC) AS UserMonthRank,
    ROW_NUMBER() OVER (PARTITION BY MonthStart ORDER BY MonthTotalAmount DESC) AS MonthUserRank
FROM #UserMonthlySummary;

很多新手一听到窗口函数就发怵，其实关键就是理解PARTITION BY是分组范围，ORDER BY是组内排序逻辑。你自己实战跑几次，多换换分组条件，就能找到感觉。

选择RANK()还是ROW_NUMBER()，取决于业务需求。如果金额并列，你要不要给相同名次？只要并列顺序无所谓，就无脑ROW_NUMBER()，它保证每行编号唯一。如果需要并列跳号，用RANK()。DENSE_RANK()则不跳号，并列之后下一个序号紧跟。三种函数在报表场景里各有用途，可以先跑跑看再决定用哪个。

因为我只需要最终结果，所以就在这一步把查询结果直接落进临时表，避免在原表上反复跑窗口函数：

sql复制SELECT
    UserId,
    MonthStart,
    MonthOrderCount,
    MonthTotalAmount,
    RANK() OVER (PARTITION BY UserId ORDER BY MonthTotalAmount DESC) AS UserMonthRank
INTO #RankedSummary
FROM #UserMonthlySummary;

4.5 第四步：关联用户信息，输出最终结果

最后一步把用户表关联上，把运营需要展示的字段拿出来：

sql复制SELECT
    u.UserName,
    u.CityName,
    r.MonthStart,
    r.MonthOrderCount,
    r.MonthTotalAmount,
    r.UserMonthRank
FROM #RankedSummary AS r
INNER JOIN dbo.Users AS u ON r.UserId = u.UserId
ORDER BY r.UserMonthRank, r.MonthTotalAmount DESC;

这一步就是纯粹的展示层查询，逻辑简单清爽。回过头来对比一下，如果所有逻辑都写一条大SQL，你可能要对付四层嵌套子查询加两三个窗口函数，写出来一大坨，可读性和执行效率都很难兼顾。现在拆成四段，每段都能单独跑、单独验数，出了问题也能快速定位是哪一步数据不对。这就是临时表最有价值的地方。

4.6 完整过程中我的几个实操心得

• 第一步圈选数据时，一定要把过滤条件下推到源头。不要在临时表已经很大的时候再去过滤，临时表越小，后面每一步越快。
• 每次开始创建临时表之前，先执行一次条件删除：

sql复制IF OBJECT_ID('tempdb..#OrderBase') IS NOT NULL
    DROP TABLE #OrderBase;

• 这能防止存储过程或脚本重复执行时报“对象已存在”的错误。
• 用完临时表立刻手动清理，别把清理工作留给系统。我习惯在脚本结束时统一加一段清理，例如：

sql复制IF OBJECT_ID('tempdb..#RankedSummary') IS NOT NULL DROP TABLE #RankedSummary;
IF OBJECT_ID('tempdb..#UserMonthlySummary') IS NOT NULL DROP TABLE #UserMonthlySummary;
IF OBJECT_ID('tempdb..#OrderBase') IS NOT NULL DROP TABLE #OrderBase;

• 数据量大的临时表，在不需要索引的情况下避免额外加索引。因为索引会增加tempdb写操作，临时表生命周期短，索引的使用效率可能没那么划算。如果确实要反复关联，加主键或聚集索引，对性能帮助明显。

这段实操过程也不限于SQL Server。MySQL里用CREATE TEMPORARY TABLE和DROP TEMPORARY TABLE完全能做到同样的分步逻辑。不同数据库语法细节不同，但“分步落中间结果”的设计思路是完全一致的。

5. 常见问题与性能陷阱排查

5.1 临时表明明删了，怎么还报“对象已存在”

这是最常遇到的问题之一。脚本重复执行的时候，如果第一次执行没有清理临时表，第二次再用CREATE TABLE #Temp就会报错。有的人觉得系统会自动清理就真不清理了，但在同一个会话里只要连接不断，临时表会一直在，直到会话关闭或显式删除。

解决办法开头已经写了，就是在创建前做一次存在性检查。SQL Server里用OBJECT_ID('tempdb..#TempName')判断非常可靠。MySQL里可以用DROP TEMPORARY TABLE IF EXISTS temp_name，直接顺手清理旧表。

5.2 临时表大量使用导致tempdb空间暴涨

如果一个实例上并发运行多个都用临时表的重型任务，tempdb可能会以惊人的速度膨胀。常见原因有：临时表里塞了太多数据、排序操作过多、临时表创建后没有及时删除、事务持续时间过长导致清理延迟。

我的建议是：

• 尽量提前过滤数据再入临时表，原则是临时表越瘦越好。
• 用完即删，用DROP TABLE主动释放空间。
• 检查有没有长时间未提交的事务，它会拖住tempdb的版本存储，让空间无法清理。
• SQL Server可以考虑为tempdb增加数据文件，但注意多数据文件要等大，不能一个文件狂热增长，其他文件空闲。
• 对超大临时表的频繁写入，考虑把事务拆小，避免大事务占用过多资源。

5.3 临时表查询慢，该怎么办

明明数据量不大，临时表查询却慢得离谱？最常见的原因是：临时表没有索引，而且没有统计信息，SQL Server只能根据表扫描来判断成本，一旦临时表参与关联，执行计划可能会选错。尤其当你用SELECT INTO创建临时表，后续直接关联大表时，优化器以为临时表只有几行，实际有几百万行，生成的执行计划就是灾难级别的。

解决思路：在大临时表创建完成后，主动更新统计信息或者直接建索引。操作上不是让你上来就无脑加索引，而是根据后续查询语句里的关联键和过滤条件，在关键列上建索引。比如刚才那个场景，#UserMonthlySummary要按UserId关联用户表，我就在建表时把UserId设为索引列，这一步收益立竿见影。

另外排序操作也会拖慢临时表相关查询。排序一般发生在GROUP BY、ORDER BY、DISTINCT和窗口函数上。如果临时表数据量大、排序字段多，给排序字段建个索引也可能有帮助。不过临时表建完马上用，索引也会增加写入成本，需要自己权衡。

5.4 临时表跟正式表同名的风险

有些开发者图省事，给临时表起一个跟正式表一样的名字。大部分数据库是允许的，比如MySQL中临时表优先于正式表被读取。这会导致什么后果？你写代码时以为是查正式表，实际读到的却是临时表，或者反过来，正式数据已经更新了你却一直读到临时表里的旧数据。

这类问题非常隐蔽，排查起来极其痛苦。我的习惯是临时表必须带统一前缀，比如#tmp_开头，正式库里的表几乎不可能叫这名字，从根源上杜绝冲突。

5.5 长期运行的连接里，临时表占着资源不释放

连接池在应用系统里太常见了。如果应用代码里创建了一个临时表，然后连接归还给连接池，很多时候临时表不会立刻被回收（视连接是否真正关闭而定）。如果应用频繁执行这类操作，连接池里的每个连接都可能残留着临时表，tempdb里的对象越堆越多。

SQL Server里可以通过以下语句查看当前有哪些临时表：

sql复制SELECT
    [name],
    [create_date]
FROM tempdb.sys.tables
WHERE [name] LIKE '#%'
ORDER BY [create_date] DESC;

找到异常残留的临时表，可以手动清理，但更根本的解决方案是在应用代码里用完临时表就显式删除。如果是自己写SQL，就养成好习惯；如果是维护别人留下的烂摊子，先杀残留对象，再改代码逻辑。

5.6 临时表与事务之间相互影响

临时表在事务里也有一些偏门但值得注意的细节。事务回滚的时候，临时表里的数据修改会自动回滚，但临时表本身的创建和删除不会回滚。比如你事务里执行了CREATE TABLE #T，插入了数据，然后回滚，数据插入会被撤销，但#T这个表已经存在了。这一点在写复杂事务时要特别注意，别指望回滚能帮你把创建的表清掉。

如果事务比较长，临时表会拖住事务的持续时间，间接影响锁的持有和版本记录的清理。对于需要大事务的场景，建议把临时表的创建放到事务外，能用小事务就用小事务。

5.7 排查思路总结

遇到跟临时表相关的性能问题，我基本顺序是：先用上面的DMV语句看tempdb里有什么，再用sp_spaceused看临时表占多大空间，接着看执行计划里有没有表扫描、缺失索引警告，最后检查统计信息和索引情况。90%的问题都能在这几步里定位清楚，不需要一上来就动服务器配置。

6. 创建临时表高频问题速查表

这张表我建议你存下来放在手边，写临时表遇到问题先对一遍。大部分问题不是复杂的架构问题，就是一些基本习惯没做到位。

7. 几个容易忽略的进阶细节

7.1 命名规则和规范化

临时表的命名虽然不像正式表那么严格，但也别太随意。命名里最好能带上这个表是干什么的。比如#OrderDailySummary就比#T1清楚得多。代码不是只给你自己看的，半个月之后再打开一个脚本，看到满屏#T1、#T2，你自己也得想半天。推荐在所有SQL脚本里统一临时表前缀和命名风格。

SQL Server里本地临时表的名称最长可达116个字符（算上#号），所以该写清楚的尽量写清楚。

7.2 大临时表里必要的字段类型和长度检查

SELECT INTO自动推断类型这个特性，平时很爽，但在某些边缘情况下会坑你。例如VARCHAR类型的数据，如果源数据里很长，推断可能变成VARCHAR(MAX)，这样的列无法建索引。又比如数值型字段，推断出的精度和标度可能不是你想要的。

我建议在涉及关键字段时，明确写CAST或CONVERT来固定类型。例如：

sql复制SELECT
    CAST(UserId AS INT) AS UserId,
    CAST(TotalAmount AS DECIMAL(18,2)) AS TotalAmount,
    CAST(Memo AS NVARCHAR(200)) AS Memo
INTO #TempFixed
FROM SourceTable;

代码是长了点，但换来的是稳定的结构和后续查询的高效。

7.3 在临时表上建立索引的几种具体写法

按不同情况，建索引的方式不一样。如果是CREATE TABLE建的表，可以在CREATE TABLE语句里直接定义主键或者索引。但如果是SELECT INTO建的表，需要事后补建：

sql复制CREATE INDEX IX_TempOrderBase_UserId ON #OrderBase(UserId);
CREATE INDEX IX_TempOrderBase_OrderDate ON #OrderBase(OrderDate);

也可以建包含多个列的复合索引：

sql复制CREATE INDEX IX_TempOrderBase_User_Date ON #OrderBase(UserId, OrderDate);

索引建太多会影响写入性能，临时表又是短命数据，所以只要在关键查询路径上建少数几个索引就够了，别把正式表那套索引策略全套搬过来。

7.4 临时表也可以修改结构

有些场景下，建完临时表之后又觉得少一列，可以直接用ALTER TABLE加列：

sql复制ALTER TABLE #OrderBase ADD CostAmount DECIMAL(18,2);

加完列之后可以用UPDATE回填数据，这与正式表的操作没什么区别。只是注意一点：如果临时表参与了很多查询，加列操作本身可能导致执行计划失效，需要重新编译。具体场景中，如果加列之后发现查询变慢，可以查一下是否有计划缓存的问题。

7.5 利用临时表优化分页查询

很多时候分页慢是因为数据库要把所有符合条件的数据都找出来，排序后再取其中一小段。如果数据过滤逻辑复杂、排序字段多，每次都重算一遍开销极大。一种优化思路是把“页码无关”的重计算提前到临时表里。比如一个筛选条件涉及到五六张表关联，无论用户翻到第几页，这个关联结果都需要算一遍。这种场景下可以先把关联结果落到临时表，再在临时表上做分页，这样只需要算一次关联，之后翻页都面对一个轻量的结果集。

SQL Server的分页写法通常用OFFSET FETCH：

sql复制SELECT *
FROM #FilteredData
ORDER BY CreateTime DESC
OFFSET 0 ROWS
FETCH NEXT 20 ROWS ONLY;

MySQL里对应的是LIMIT：

sql复制SELECT *
FROM temp_filtered_data
ORDER BY create_time DESC
LIMIT 20 OFFSET 0;

这样做响应速度会提升得非常明显。

7.6 临时表别替代正式统计表

需要提醒一句：临时表是工具，不是设计模式。如果你发现某个逻辑里反复创建同一个结构的临时表，从不同入口多次执行，那这个中间结果很可能应该建成一张正式的统计表或物化视图，而不是每次现算现用。判断依据可以很简单：这个中间表是有明确业务含义、会被多个模块复用的？那就不要放临时表里了，建一张正式的表好好维护。临时表适合的是“一次性任务里的中间过程”，而不是“反复使用的公共数据资产”。

8. 我自己踩过的几个临时表大坑

先说一个真实经历。有一回线上报表突然变慢，排查下来发现是某个存储过程被人加了一段临时表逻辑，里面用SELECT * INTO #BigDetail FROM SomeBigTable，把一张几亿行的明细全量塞进了临时表，然后只用到其中很少几列。几亿行明细完整写进tempdb，磁盘空间瞬间告急，连同实例上其他业务的查询全被拖垮。后来我把这段改成先做列裁剪和过滤，再进临时表，报表速度反而比以前还快了不少。这个教训让我养成了一个习惯：数据进临时表之前，永远先想清楚哪些行、哪些列是真正需要的。

还有一个跟连接池相关的坑。应用层用连接池连数据库，代码里创建了临时表存储数据，执行完没删，也不关闭连接。连接归还池子之后，临时表一直留在那个连接对应的会话里。后来应用高并发一跑，tempdb里堆积了几百个类似的临时表，每个还都有不小的数据量，数据库性能肉眼可见地下降。那次排查花了不少时间，最后找到根因后，我在代码里和数据库端同时加了清理逻辑，才彻底解决。所以大家一定要记住：连接池不是免费的午餐，用完临时表不删等于把垃圾留在公共区域。

还有一个动态SQL作用域的坑，某次写脚本时也踩过。之前详细讲过，这里再强调一遍：动态SQL内部创建的本地临时表，外面访问不到，这不是玄学，是作用域规则。养成外层建表、内部填数，或者使用全局临时表的习惯，可以避开这类莫名其妙的报错。

临时表这东西，入门时觉得简单，越用越觉得里面有门道。我个人在实际操作中的体会是：SQL写得漂不漂亮，很多时候不看会不会花哨的语法，而是看能不能把复杂任务拆成清晰、可控的步骤——临时表正是做拆解的利器。希望这篇关于创建临时表方法的总结，能在你日常写SQL、做报表、优化查询时派上用场，少踩几个我当初踩过的坑。