SQL临时表创建与性能优化：从语法到实战的完整指南

项目标题给得挺清楚：SQL里创建临时表的方法总结。但真正做数据分析、写存储过程、搞报表开发的人都知道，临时表这玩意儿绝不止是“会写两句CREATE TABLE #temp”这么简单。它牵扯到会话生命周期、存储引擎、日志开销、索引策略、锁竞争，甚至还有SQL Server和MySQL、PostgreSQL之间的行为差异。这篇文章就以临时表为主线，把创建方式、适用场景、踩坑细节一次讲透。不管是刚入门的数据新人，还是被慢查询折磨的运维老手，都能在这里找到能直接抄作业的内容。

1. 临时表究竟解决什么问题

临时表这个名字听起来很直白，但在实际项目中，很多人对它的理解只停留在“把中间结果存起来”这个层面。其实临时表的核心价值是：把一个复杂的、多步骤的数据处理流程，拆解成多个可验证、可复用、可索引的中间结果集。

举个例子。你在做月度销售报表时，需要先汇总订单明细，再关联客户维度表，最后按区域和产品线做透视。如果全部用一条巨型SQL搞定，不仅写起来痛苦，而且一旦某个中间环节出错，整条SQL都要重新跑一遍。更麻烦的是，优化器在这种巨型SQL里往往选不到理想的执行计划，导致明明数据量不大，查询却慢得离谱。

这时候临时表就派上用场了。你可以把订单明细汇总先放进临时表，加上索引，再逐步关联、聚合。每一步都能独立验证正确性，出问题也能快速定位到具体环节。数据量一旦到了百万级以上，这种“分步走”的方法在性能上几乎总是优于一条龙式的复杂JOIN。

除了拆解复杂查询，临时表在以下几种场景里也是刚需：

• 存储过程内部需要多次引用同一个中间结果集，避免重复扫描原表。
• 需要把多个来源的数据（比如跨库查询、异构数据库导入）先合并清洗，再进入后续流程。
• 数据校验、对账、ETL的中间落盘，需要保留一份可回溯的数据快照。
• 游标遍历过程中需要记录状态、聚合结果或临时计算值。
• 在一个会话内跨多个SQL语句共享数据，又不想建一张永久表占用数据库空间。

临时表并不是为了“临时”而临时，它是SQL开发中一种典型的空间换时间、阶段换可靠的工程化手段。理解了这一点，再看那些五花八门的创建语法，心里就有谱了。

1.1 临时表和普通表到底差在哪

要搞清楚临时表，先得知道它和普通表的关键差异。普通表是持久化存储在数据库中的对象，所有人都能按照权限访问，数据生命周期是持久的，除非你显式DROP掉。临时表则不同，它只存在于当前会话（或者当前批处理）中，会话结束后自动销毁。

这个特性带来几个直接影响：

第一，命名空间隔离。SQL Server里临时表以#开头，它存储在tempdb数据库中，多个会话各自创建同名的#temp表互不干扰。MySQL里临时表用TEMPORARY关键字定义，也是会话私有，外部会话完全看不到。

第二，DDL和数据一起消失。临时表用完即走，不需要专门写清理逻辑。这在大规模自动化脚本里很省心，不用担心垃圾表堆积，也不用担心误操作删掉别人的数据。

第三，权限控制更简单。普通表要分配SELECT、INSERT、UPDATE等各类权限，临时表则只对创建者可见，天然带了权限隔离。

不过这里有个常见误区：临时表不等于内存表。很多人以为临时表就是存在内存里的，访问速度飞快。实际上SQL Server的临时表默认落在tempdb磁盘上，MySQL的临时表在5.7及之后版本中默认使用Memory引擎（超过限制后会自动转成磁盘表），但也是可能落盘的。它快的关键不在于内存，而在于不用写完整的事务日志、数据量小、生命周期短，因此锁定和IO开销都更轻。

2. 创建临时表的几种主流方式

不同数据库产品对临时表的语法支持差异不小。下面以SQL Server、MySQL、PostgreSQL三种主流数据库为例，逐个梳一遍。你如果主要用其中一种，直接跳到自己熟悉的段落即可；如果做跨数据库开发，这一节帮你建立全局视图。

2.1 SQL Server中的创建方式

SQL Server的临时表分两类：局部临时表（Local Temporary Table）和全局临时表（Global Temporary Table）。创建语法差异只差一个#号，但语义完全不同。

局部临时表的标准写法：

sql复制-- 方式一：创建临时表并插入数据
SELECT 
    OrderID,
    CustomerID,
    SUM(Amount) AS TotalAmount
INTO #OrderSummary
FROM Orders
WHERE OrderDate >= '2025-01-01'
GROUP BY OrderID, CustomerID;

这种方式叫SELECT ... INTO，一条语句搞定建表+插入，表结构由查询结果的元数据自动推断。优点非常明显：代码简洁，不需要先写CREATE TABLE定义每个字段。缺点是需要额外处理索引，因为SELECT INTO不会把源表的索引、约束、触发器带过来。

sql复制-- 方式二：先建表，再插入
CREATE TABLE #CustomerAgg (
    CustomerID INT NOT NULL,
    OrderCount INT,
    LastOrderDate DATETIME,
    PRIMARY KEY (CustomerID)
);

INSERT INTO #CustomerAgg (CustomerID, OrderCount, LastOrderDate)
SELECT 
    CustomerID,
    COUNT(*),
    MAX(OrderDate)
FROM Orders
GROUP BY CustomerID;

这种方式多了写表结构的步骤，但好处是你能精确控制字段类型、长度、以及索引和约束。在数据量较大且需要反复查询临时表时，建议用方式二，因为可以提前规划主键和索引。

全局临时表的语法就是在#基础上加一个，变成##：

sql复制CREATE TABLE ##GlobalTemp (
    ID INT,
    Value VARCHAR(100)
);

全局临时表一旦创建，所有会话都能看见和访问，直到最后一个引用它的会话断开连接才会自动销毁。这个特性适合跨会话共享临时数据，但要格外小心中途连接异常导致的锁和阻塞问题。

另外SQL Server还有一种非常像临时表的对象：表变量。

sql复制DECLARE @OrderTable TABLE (
    OrderID INT,
    Amount DECIMAL(18,2)
);

INSERT INTO @OrderTable VALUES (1, 99.50);

表变量和临时表的核心差异总结如下：

我这里给出一个实战建议：数据量在几百行以内的临时计算，用表变量；几千行以上的多步骤处理，用临时表。表变量没有统计信息，优化器容易对数据量产生严重误判，一旦超过几千行，很容易出现内存溢出或执行计划剧烈变差的问题。

2.2 MySQL中临时表的正确姿势

MySQL的临时表使用TEMPORARY关键字创建：

sql复制CREATE TEMPORARY TABLE temp_order_summary AS
SELECT 
    customer_id,
    COUNT(*) AS order_count,
    SUM(amount) AS total_amount
FROM orders
WHERE created_at >= NOW() - INTERVAL 30 DAY
GROUP BY customer_id;

这种CREATE TABLE ... AS SELECT的写法在MySQL里很常见，建表和数据填充一步到位。但要注意：它不会复制源表的索引，如果后续要根据customer_id做高并发查询，建议建完临时表后手动补充索引。

sql复制CREATE TEMPORARY TABLE temp_order_summary (
    customer_id INT NOT NULL,
    order_count INT,
    total_amount DECIMAL(18,2),
    PRIMARY KEY (customer_id)
) ENGINE = InnoDB;

INSERT INTO temp_order_summary
SELECT 
    customer_id,
    COUNT(*),
    SUM(amount)
FROM orders
WHERE created_at >= NOW() - INTERVAL 30 DAY
GROUP BY customer_id;

MySQL里也可以使用CREATE TEMPORARY TABLE ... LIKE来直接复制一张永久表的结构，然后按需插入数据：

sql复制CREATE TEMPORARY TABLE temp_users LIKE users;

INSERT INTO temp_users
SELECT * FROM users WHERE status = 1;

这个方式的好处是表结构、索引、默认值等元数据一次性都继承过来了，适合做数据备份、归档、类型转换等操作。

MySQL临时表的一个重要限制是：同一会话中，临时表不能和永久表同名，否则会提示已经存在。虽然同名时临时表会遮蔽永久表，但极易造成混乱，特别是后续不小心执行了DROP TABLE，可能误删了永久表。在实际开发中，建议用明确的temp_前缀命名，从根上避免这个坑。

2.3 PostgreSQL的临时表细节

PostgreSQL创建临时表的基本语法：

sql复制CREATE TEMPORARY TABLE temp_orders (
    order_id INTEGER,
    order_date DATE,
    amount NUMERIC
);

也支持CREATE TEMP TABLE，两者是等价的。PostgreSQL同样支持从查询结果直接建表：

sql复制CREATE TEMPORARY TABLE temp_order_stats AS
SELECT 
    customer_id,
    SUM(amount) AS total_amount
FROM orders
GROUP BY customer_id;

PostgreSQL临时表有一个特有的好设计：默认情况下，临时表的数据随会话结束自动销毁，但表结构在事务回滚时如何留存，行为由ON COMMIT选项控制。这里有三个选项：

• ON COMMIT PRESERVE ROWS：事务提交后数据保留，会话结束才清理。
• ON COMMIT DELETE ROWS：事务提交后清空所有行，但表结构保留。
• ON COMMIT DROP：事务提交后直接删除整个临时表。

sql复制CREATE TEMPORARY TABLE temp_calc (
    id INT,
    result NUMERIC
) ON COMMIT DROP;

这个特性在做“事务内临时计算”时很有价值。比如你在一个事务里需要分步执行多个查询，中间结果仅在本事务内使用，那么ON COMMIT DROP是最稳妥的，事务一结束连表带数据自动消失，连清理工作都不用做。

还有一个需要注意的地方：PostgreSQL的临时表可以和永久表重名，此时临时表会优先于永久表被访问。这个机制在某些场景是特性（用临时表遮蔽某个大表做测试），但也容易埋雷。我的习惯是：如果不需要遮蔽，就给临时表加tmp_前缀，避免掉进这个坑。

3. 临时表的高级玩法：索引、CTE和性能调优

创建临时表不是目的，让后续查询跑得快才是目的。临时表本身不复杂，但配合索引和CTE，能衍生出很多高效的SQL写法。

3.1 CTE和临时表怎么选

CTE（Common Table Expression，公用表表达式）是临时表最常见的替代方案。它的好处是只用一条SQL就能实现递归查询和分步计算，不需要创建任何物理对象。比如：

sql复制WITH order_summary AS (
    SELECT 
        customer_id,
        COUNT(*) AS order_cnt,
        SUM(amount) AS total_amount
    FROM orders
    GROUP BY customer_id
)
SELECT *
FROM order_summary
WHERE total_amount > 10000;

CTE和临时表的核心区别在于结果集是否物化。CTE本质上是一个内联视图，多数数据库优化器会在执行时把它解析到主查询中，而不是物理落盘。因此在简单场景里，CTE更轻量、性能更好。但问题来了：当一个CTE被后续多个JOIN引用时，优化器可能会把CTE部分多次展开、重复扫描，反而导致性能下降。

以我的经验，有个非常实用的取舍标准：

• 中间结果被引用1次或2次，且数据量不大，用CTE。
• 中间结果被引用3次以上，或者后续查询很复杂、需要加索引，用临时表。
• 需要递归查询，且层级很深、数据量可控，用递归CTE。
• 需要在存储过程中分步验证中间结果、调试SQL，用临时表。

在MySQL 8.0里，CTE默认采用物化策略，如果CTE在主查询中被多次引用，会先物化成内部临时表。这里的物化行为有时候反而比反复嵌套子查询高效得多。但需要注意，MySQL对CTE物化的优化并不是你写了WITH它就一定物化，还是依赖优化器的判断。为了拿到确定性高、可控性强的行为，宁可显式建临时表。

3.2 临时表索引的正确打开方式

建临时表的速度通常不是核心痛点，真正影响整体性能的是临时表上的索引结构。我在SQL Server里做过几百张临时表的性能对比，有一条铁律：凡是后续要进行JOIN或过滤的字段，必须在临时表上建索引。否则优化器只能用文件排序（sort）或哈希匹配（hash match）兜底，数据量一大就跑得飞慢。

SQL Server中建临时表时的索引写法：

sql复制CREATE TABLE #TempSales (
    RegionID INT NOT NULL,
    ProductID INT NOT NULL,
    SalesAmount DECIMAL(18,2)
);

-- 建议：在JOIN字段上建索引
CREATE INDEX IX_TempSales_RegionID ON #TempSales(RegionID);
CREATE INDEX IX_TempSales_ProductID ON #TempSales(ProductID);

MySQL建临时表并加索引：

sql复制CREATE TEMPORARY TABLE temp_sales (
    RegionID INT NOT NULL,
    ProductID INT NOT NULL,
    SalesAmount DECIMAL(18,2),
    KEY idx_region (RegionID),
    KEY idx_product (ProductID)
) ENGINE = InnoDB;

这里有个实操细节：临时表的索引设计不能照搬原表。因为临时表里的数据往往是聚合、过滤后的结果集，数据分布大概率已经变了。如果临时表只有几万行，而你在上面建了四五个索引，索引维护的开销可能比扫描整张表还贵。我的习惯是：少于5万行的临时表只建1个聚集索引或主键；10万行以上再考虑复合索引，而且复合索引的字段顺序必须和后续查询的WHERE和JOIN完全匹配。

3.3 临时表配合批量更新实战

临时表最常见的应用之一是批量更新。比如需要在订单表里根据客户分层更新VIP标记，如果直接写一条UPDATE JOIN，性能通常很差，而且容易锁表。分步用临时表做，效果立竿见影：

sql复制-- Step 1: 把客户分层结果放入临时表
CREATE TABLE #CustLevel (
    CustomerID INT PRIMARY KEY,
    LevelCode VARCHAR(10)
);

INSERT INTO #CustLevel
SELECT 
    CustomerID,
    CASE 
        WHEN TotalAmount > 100000 THEN 'VIP'
        WHEN TotalAmount > 10000 THEN 'GOLD'
        ELSE 'NORMAL'
    END AS LevelCode
FROM (
    SELECT CustomerID, SUM(Amount) AS TotalAmount
    FROM Orders
    WHERE OrderDate >= '2025-01-01'
    GROUP BY CustomerID
) t;

-- Step 2: 用临时表批量更新主表
UPDATE c
SET c.VipLevel = lv.LevelCode
FROM Customers c
INNER JOIN #CustLevel lv ON c.CustomerID = lv.CustomerID;

这种做法的好处是：先在小结果集上完成所有聚合计算，再利用主键索引做关联更新，事务时间短、锁范围小。如果直接在Orders表上做庞大的UPDATE JOIN，执行计划往往需要扫描大量数据，还可能因为统计信息不准而踩到全表扫描。

4. 临时表在真实场景中的完整案例

光讲语法和概念，总感觉少了一点真实感。这里分享一个我前段时间帮业务团队优化的实际案例，恰好涉及临时表的完整使用过程。

业务背景是，某个数据部门每天需要生成一份“销售区域经理KPI日报”，数据来源包括：订单明细表（单日约80万行）、销售区域表（约5000行）、员工信息表（约2万行）、历史KPI指标表（约200万行）。原来的做法是一个巨型SQL，8个数据源全部JOIN在一起，跑一次要25分钟，而且经常超时。

我的优化思路就是用临时表把整个流程拆成四步。

第一步，先把当天的订单明细做一次预聚合，只保留需要字段，并过滤掉无效订单：

sql复制CREATE TABLE #OrderDaily (
    RegionID INT,
    EmpID INT,
    OrderCnt INT,
    SalesAmt DECIMAL(18,2)
);

INSERT INTO #OrderDaily
SELECT 
    o.RegionID,
    o.EmpID,
    COUNT(*) AS OrderCnt,
    SUM(o.Amount) AS SalesAmt
FROM Orders o
WHERE o.OrderDate = '2025-05-12'
  AND o.Status <> 'CANCELLED'
GROUP BY o.RegionID, o.EmpID;

这里把80万行压成了大概400行聚合结果，后续所有JOIN的数据量级都降下来了。

第二步，关联员工和区域信息，加上维度字段：

sql复制CREATE TABLE #KpiRaw (
    RegionID INT,
    RegionName VARCHAR(50),
    EmpID INT,
    EmpName VARCHAR(50),
    OrderCnt INT,
    SalesAmt DECIMAL(18,2)
);

INSERT INTO #KpiRaw
SELECT 
    o.RegionID,
    r.RegionName,
    o.EmpID,
    e.EmpName,
    o.OrderCnt,
    o.SalesAmt
FROM #OrderDaily o
INNER JOIN Regions r ON o.RegionID = r.RegionID
INNER JOIN Employees e ON o.EmpID = e.EmpID;

第三步，和KPI目标表做对碰，计算达成率：

sql复制CREATE TABLE #KpiFinal (
    RegionName VARCHAR(50),
    EmpName VARCHAR(50),
    ActualAmt DECIMAL(18,2),
    TargetAmt DECIMAL(18,2),
    Ach_Rate DECIMAL(5,2)
);

INSERT INTO #KpiFinal
SELECT 
    k.RegionName,
    k.EmpName,
    k.SalesAmt,
    ISNULL(t.TargetAmt, 0) AS TargetAmt,
    CASE 
        WHEN t.TargetAmt > 0 THEN CAST(k.SalesAmt / t.TargetAmt * 100 AS DECIMAL(5,2))
        ELSE 0
    END AS Ach_Rate
FROM #KpiRaw k
LEFT JOIN KpiTarget t 
    ON k.RegionID = t.RegionID 
   AND k.EmpID = t.EmpID
   AND t.PeriodStart = '2025-05-01';

第四步，直接输出最终结果，负责生成报表的同事拿这个结果集去跑可视化即可。

优化之后，整个流程从25分钟降到了2分钟以内。根因就是：原来单条巨型SQL需要反复扫描80万行大表多次，现在每步都先压缩数据，中间表从80万行降到几百行，JOIN的成本完全不在一个量级上。这个案例也说明了一个道理：临时表不是银弹，但它是一种能让你重新控制执行路径、降低优化器负担的有效工具。

5. 临时表的经典陷阱与问题排查

临时表用多了，总会遇到各种奇奇怪怪的问题。这一节把我在实践中踩过的、或者带过的团队踩过的坑集中列一遍，每一个都是真实案例，建议收藏起来当排查手册用。

5.1 陷阱一：临时表和事务的纠缠

SQL Server中，临时表的创建和插入本身可以被事务包裹。如果事务回滚，临时表里插入的数据也会被回滚。这个行为有时候是意外的，因为很多人下意识认为临时表是“临时”的，不受事务影响。

举个例子：

sql复制BEGIN TRANSACTION;

CREATE TABLE #TempData (ID INT);
INSERT INTO #TempData VALUES (1), (2), (3);

ROLLBACK TRANSACTION;

SELECT COUNT(*) FROM #TempData;  -- 结果是0，而不是3

回滚会撤销INSERT操作，创建的表本身还在（表DDL不受事务回滚影响），但数据没了。如果你在事务中间依赖临时表的数据又没考虑回滚因素，很容易出现数据不一致的问题。

而PostgreSQL的临时表和事务的关系你可以在ON COMMIT选项中显式控制，SQL Server则没有那么精细的控制。所以在存储过程里用临时表，建议评估事务边界，不要让临时表里的关键数据跨越一个可能长时间运行的事务。

5.2 陷阱二：临时表导致的重编译

在SQL Server存储过程中，如果临时表在过程体中途创建，而且过程内部有批处理被重编译，存储过程会频繁触发重新编译，导致整体性能显著下降。

我遇到过一个真实案例：存储过程里先创建临时表，插入数据，然后动态拼接SQL查询临时表，最后又做了几次ALTER TABLE给临时表加列。整个过程触发了7次重编译，一个本应200ms跑完的存储过程硬生生跑到了8秒。

排查思路很简单：打开SQL Server Profiler或者查询sys.dm_exec_query_stats，看plan_generation_num字段是否异常高。如果发现临时表和重编译绑定在一起，优化方向是：预定义完整的临时表结构，避免多次ALTER；把整个逻辑拆成多个子存储过程，每个过程内部保持稳定的执行计划；有条件的话改用表值参数替代临时表。

5.3 陷阱三：临时表的统计信息缺失

临时表默认是不会自动维护统计信息的，至少在SQL Server中，当临时表参与JOIN时，优化器会基于创建临时表时的行数估计来生成执行计划。如果你先向临时表插入少量数据，接着又插入几百万行，优化器可能仍然以几百行的规模评估，选索引时就会出现严重偏差。

MySQL的情况类似，如果临时表涉及比较大的数据量，建议在插入完成后手动执行：

sql复制ANALYZE TABLE temp_order_summary;

SQL Server中一般用UPDATE STATISTICS手工刷新：

sql复制UPDATE STATISTICS #OrderSummary;

这个动作虽然多了一步，但在数据量变化超过10倍时，对执行计划的改善是质的飞跃。我见过很多“临时表越用越慢”的案例，排查到最后都是统计信息过期惹的祸。

5.4 陷阱四：tempdb的压力和空间

SQL Server的临时表统一存储在tempdb，如果系统里同时有大量会话在创建大临时表，tempdb可能迅速膨胀，甚至占满磁盘空间。线上系统因为这个原因崩溃的案例并不少见。

排查和预防可以从几个角度入手：

• 监控tempdb的使用量和自动增长事件：

  sql复制SELECT 
      name,
      size * 8 / 1024 AS SizeMB,
      growth * 8 / 1024 AS GrowthMB,
      is_percent_growth
  FROM tempdb.sys.database_files;
  

• 提前调整tempdb的数据文件数量和初始大小。SQL Server默认只有一个tempdb数据文件，并发高时极易成为瓶颈。建议按CPU核心数设置多个等大的数据文件。
• 避免在临时表里存放超大字段或大文本，不是必要的话不要SELECT *进临时表。
• 用完临时表尽量显式DROP TABLE，尤其是在长会话里。虽然连接关闭时系统会自动清理，但连接池复用时临时表可能残留。

MySQL中临时表的磁盘溢出问题通常表现为：使用Memory引擎的临时表超过tmp_table_size和max_heap_table_size后自动转为磁盘上的InnoDB临时表，性能瞬间下降。优化方向是调大这两个参数，同时优化SQL，减少中间结果集膨胀。

5.5 陷阱五：死锁与阻塞

临时表上的锁竞争经常被忽视。SQL Server中多个会话各自创建同名#temp表不会互相阻塞，因为它们的内部对象名是唯一的（系统会自动追加后缀）。但如果你用了全局临时表##temp，情况就完全不同了，所有会话共享同一份数据，锁冲突和死锁的概率直线上升。

MySQL中临时表的锁行为取决于存储引擎。InnoDB临时表同样有行锁和表锁的概念，高并发写入临时表时也可能发生死锁。我建议：临时表的高并发写入尽量限定在会话内部完成，不要跨会话共享可变状态的临时表。

死锁排查通用方法：

• SQL Server：使用SELECT * FROM sys.dm_exec_requests WHERE blocking_session_id > 0查看阻塞链。
• MySQL：使用SHOW ENGINE INNODB STATUS查看最近的死锁日志。
• 通用手段：把临时表的写入和读取拆成更小的事务，或者改成只读临时表再并发查询。

5.6 常见问题速查表

6. 创建临时表时的规范与习惯

临时表虽小，开发规范做得不好，后患无穷。我这里整理了一份我们在团队内部推广的临时表使用规范，基本上是踩了很多坑之后总结出来的，可以拿来即用。

第一，命名要有明确前缀。不同数据库习惯不同，但总的原则是能一眼看出这是临时表，而不是永久表。SQL Server习惯用#，MySQL和PostgreSQL建议加tmp_前缀。同时建议带上业务含义，比如tmp_order_daily、#SalesSummary，不要用#t1、#a这种毫无语义的名字。调试的时候你就知道带业务含义的名字救你多少次。

第二，按需指定字段，不要无脑SELECT *。临时表是用来优化性能的，把不需要的宽字段也带进来，反而增加IO和内存压力。只选取后续步骤必需的字段，是临时表设计的第一原则。

第三，入口处判断并清理残留。在存储过程或脚本里，首次使用临时表之前，养成显式判断并删除的习惯：

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

MySQL没有直接判断临时表是否存在的简洁方法，常见的做法是在DROP TEMPORARY TABLE IF EXISTS temp_table;后面直接重建。

第四，用完及时清理。虽然会话结束会释放，但在长连接中，不清理临时表会让tempdb持续增长。写存储过程时，末尾统一执行DROP TABLE，避免副作用遗留。

第五，统一存放位置。如果公司规定临时表统一放某个库、统一前缀，就严格遵守。特别是团队协作时，全局临时表和局部临时表混用容易造成灾难。

第六，避免在事务中长时间持有临时表锁。临时表虽小，也是有锁的。如果事务长时间运行，临时表上的锁也可能阻塞其他进程。能用表变量替代的短事务操作，就别用临时表。

7. 临时表之外的替代方案

最后补充一点扩展视野的内容。临时表虽好，但不是唯一选择，也不是所有场景下的最优选择。了解替代方案，能帮你更精准地选择工具。

通用表表达式（CTE），前面讲过，适合单条SQL里的轻量级分步查询，不产生物理对象，代码可读性好。

永久中间表，适合跨任务、跨时段的复用。比如每日跑批任务里的日汇总表，如果多个下游都依赖它，建一张带索引的永久中间表比每天反复建临时表划算得多。定时清理策略跟上，这类表并不会成为垃圾。

表值函数，SQL Server中可以用内联表值函数或多语句表值函数，把一段固定的逻辑封装成“可参数化的临时表”。优点是复用性强，缺点是性能开销比直接查临时表大。

表值参数（Table-Valued Parameter，TVP），适合把应用程序里的数据集合传给存储过程。相比临时表，它类型安全、事务边界清晰，但数据量太大时性能不如临时表。

视图，把逻辑封装成视图，在多个查询里直接引用。视图不落盘，适合不需要中间结果的场景，但复杂视图叠加过多后会导致优化器负担加重，性能难调。

窗口函数，很多原本需要临时表做的分组聚合、排名计算，用窗口函数（ROW_NUMBER、SUM OVER等）一条SQL就能搞定。能不用临时表就不用的原则，在大多数情况依然成立。

内存缓存/分析引擎，如果临时表的数据是给报表和BI用的，可以考虑用ClickHouse、Doris这类分析型数据库直接处理，它们对临时数据集的处理效率和并发能力远高于传统OLTP数据库的临时表。

这些替代方案之间并不是彼此取代的关系，而是要看具体场景选择。我的设计原则很简单：优先单条SQL解决，其次CTE，再其次临时表，最后才考虑永久中间表和外部分析引擎。

回到临时表本身，它的价值不仅在语法层面的“创建”，更在于你把复杂问题拆解为多个可管理步骤的能力。SQL写得好不好，很多时候不取决于你掌握了多少高级特性，而在于你能不能把一个大问题分解成若干小问题，用最合理的工具逐个击破。临时表就是这套方法论中最趁手的基础工具之一。我在实际排查中遇到的大多数慢查询，最后都不是靠某个奇技淫巧解决的，而是老老实实把大查询拆开、分步落临时表、重新设计索引。这套笨办法，比什么高级优化都靠谱。