临时表全解析：四大数据库创建方法、生命周期与踩坑指南

做数据库开发这些年，我越来越觉得临时表是 SQL 里最被低估的一类对象。很多人写复杂查询时习惯一条 SQL 拼命嵌套子查询，结果跑出来慢得离谱；也有人把临时表当正式表用，离职三个月后表还挂在库里被人追着问。今天我就把“临时表创建”这件事系统地捋一遍，覆盖 MySQL、SQL Server、PostgreSQL、Oracle 四种主流数据库的语法差异、生命周期和实际踩坑经验。不管你是刚学 SQL 的新手，还是已经在和慢 SQL 优化的老手缠斗多年的开发者，这篇文章应该都能帮你省下不少折腾时间。

1. 临时表解决什么问题，先弄清分类再动手

临时表并不是一个数据库的独有特性，而是几乎所有关系型数据库都提供的基础能力。它的核心定位是：在会话或事务的存活周期内，先把你反复用到、或者计算代价高昂的中间结果落成一张表，方便后续多次引用。听着简单，但真要解释清楚“临时表到底什么时候该用、什么时候不该用”，得先从它解决的几类典型问题说起。

1.1 复杂 SQL 拆分是临时表最大的价值

我见过太多这样的 SQL：外层套 inner join，里面又套 group by，再往里还藏着好几个标量子查询。单看逻辑，功能上没毛病，问题是要命的是性能——尤其是当中间结果集很大、又同时被多处引用的时候，数据库引擎只能一遍遍重新计算同一个中间结果。这就像做饭，每次下锅前都跑去重新洗一遍菜、切一遍菜，菜没下锅，人先累瘫了。

临时表走的则是完全不同的路子：先把菜洗好切好备在案板上，后面炒菜随取随用。对应到 SQL 里，就是先执行一条查询把中间结果“物化”到临时表，再基于这张临时表去做后续的 join、聚合、窗口计算。SQL 的可读性一下子好很多，也给了数据库优化器一个更明确的执行路径。

1.2 临时表的生命周期分类：会话级、事务级、全局级

要理解创建临时表的方法，必须先理解生命周期，因为不同数据库对临时表的存活范围定义差别很大。最基本的分类有三种：

• 会话级临时表：只能由创建它的当前会话访问，会话结束或连接关闭时自动删除。MySQL 的 TEMPORARY TABLE、SQL Server 的本地临时表 # 前缀都属于这一类。
• 事务级临时表：数据只在当前事务内有效，事务提交后数据被清空。这里要留个心眼，事务级通常指“数据”的生命周期，而非“表结构”的生命周期，Oracle 的 GTT 就是典型。
• 全局临时表：所有会话都能看到表定义，甚至可以共享数据。SQL Server 的 ## 前缀全局临时表属于这一类，但生命周期不取决于创建者，而是取决于所有引用它的会话是否关闭。

理解了这张分类图，后面看各种数据库的语法时就不会一头雾水了。很多初学者在 MySQL 里学会了 CREATE TEMPORARY TABLE，转头到了 Oracle 发现写着写着表还在、数据却没了，就是没搞懂生命周期模型完全不同。

2. 四大主流数据库创建临时表语法细节

这一章是核心干活的章节，我把实际工作中最常用的四种数据库创建临时表的方法分别讲透，包括标准语法、推荐写法、以及只在某些数据库里存在的高级用法。会给出可以直接抄走的 SQL。

2.1 MySQL / MariaDB：会话隔离，CTAS 最常用

MySQL 创建临时表的基础语法非常直白：

sql复制CREATE TEMPORARY TABLE tmp_order_stat (
    order_no   VARCHAR(32) NOT NULL,
    product_no VARCHAR(32) NOT NULL,
    total_qty  INT,
    PRIMARY KEY (order_no, product_no)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

但日常开发里最常用的往往是这种“边查边建”的方式，也就是 CTAS（CREATE TABLE AS SELECT）：

sql复制CREATE TEMPORARY TABLE tmp_goods_rank AS
SELECT 
    category_id,
    goods_id,
    sales_amount,
    ROW_NUMBER() OVER (PARTITION BY category_id ORDER BY sales_amount DESC) AS rn
FROM goods_sales_daily
WHERE stat_date = CURDATE();

这样做的好处是直接借用了查询结果的结构，省去了手写一长串字段定义的麻烦。如果你需要给临时表加主键或索引，可以在表创建完之后再执行 ALTER TABLE，也可以在建表语句里显式写出来。

使用 CTAS 方式时要注意 COLLATION、数据类型自动推导等隐性问题，尤其是从 VARCHAR 字段 SELECT 出来时，长度可能和源表完全一致，这通常没问题；但如果查询里包含 CASE WHEN 或多表 JOIN，推导出的字段类型可能会比预期更宽松。我在生产环境就见过临时表里字符串字段被自动推导成 TEXT，后续做 GROUP BY 时性能明显比 VARCHAR 差的情况。

MySQL 临时表还有几个特性需要注意：

• 当前会话断开后临时表自动消失，不需要也不能指望它跨会话共享。
• 同一会话内不允许创建两张同名临时表，除非先 DROP 掉。
• 如果临时表和真实表同名，在当前会话里，所有 SQL 访问到的都是临时表，这一点非常容易踩雷。建议给临时表起名时统一加前缀，比如 tmp_，防止误伤真实表。
• 用户需要具备 CREATE TEMPORARY TABLES 权限，大多数开发账号默认有，但只读账号往往没有。

2.2 SQL Server：本地临时表和全局临时表要分清

SQL Server 的临时表在语法上有一个很独特的标记方式，就是表名前缀。一个井号 # 表示本地临时表，两个井号 ## 表示全局临时表。

本地临时表最常见，创建方式有两种：

sql复制-- 方式一：先建表再插入
CREATE TABLE #tmp_current_rank (
    goods_id   INT,
    rank_no    INT
);

INSERT INTO #tmp_current_rank (goods_id, rank_no)
SELECT goods_id, ROW_NUMBER() OVER (ORDER BY sales_amount DESC)
FROM goods_sales_daily
WHERE stat_date = '2025-01-01';

-- 方式二：SELECT INTO 直接生成
SELECT 
    goods_id,
    ROW_NUMBER() OVER (ORDER BY sales_amount DESC) AS rank_no
INTO #tmp_goods_rank
FROM goods_sales_daily
WHERE stat_date = '2025-01-01';

第二种写法非常快捷，但网上不少人会忽略它的问题：SELECT INTO 不继承源表的索引、主键、标识列属性。如果只是做一次性中间结果问题不大，但如果你要在临时表上做频繁的关联查询，最好补上索引再使用。

SQL Server 的 # 临时表存放在 tempdb 中，所以它的名字相同在不同会话间不会冲突，SQL Server 会自动为表名加上内部后缀。会话结束后，表会被自动删除。不过在存储过程或批处理脚本里，我更建议显式清理，养成 DROP 的习惯：

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

这样可以避免连接池复用连接时，上一次会话遗留的临时表突然出现在新会话中，造成数据串味。这个坑不是危言耸听，我做售后支持时遇到过几次，现象就是用户偶尔复现、偶尔不复现，最后定位到连接池。

全局临时表语法如下：

sql复制CREATE TABLE ##tmp_global_rank (
    goods_id   INT,
    rank_no    INT
);

全局临时表创建后，所有会话都可以 SELECT、INSERT、UPDATE。它的删除时机是：创建它的会话断开，并且所有其他引用它的会话也断开，才会被真正回收。正是因为这个特性，全局临时表容易成为多进程协作的隐患——一个会话操作完，另一个会话没断开，表迟迟删不掉。我的建议是能不用就不用，多会话共享中间结果的场景更推荐用真实表加任务标识来管理。

顺便说一句，SQL Server 的临时表可以被创建索引，也可以被统计信息覆盖。数据量一大，统计信息的自动更新策略在临时表上可能不会那么及时，遇到执行计划明显跑偏时，可以直接执行 UPDATE STATISTICS #tmp_xxx 来手动刷新。

2.3 PostgreSQL：事务控制最灵活，ON COMMIT 三兄弟别用错

PostgreSQL 创建临时表的语法看起来和 MySQL 很像，核心是多了“事务行为”的控制：

sql复制CREATE TEMP TABLE tmp_order_stat (
    order_no   VARCHAR(32),
    product_no VARCHAR(32),
    total_qty  INT
) ON COMMIT PRESERVE ROWS;

这里的 TEMP 和 TEMPORARY 是等价的，两者都行。PostgreSQL 的临时表存储在 pg_temp 模式下，不同会话可以各自创建同名临时表，互不干扰，因此也不用像 SQL Server 那样担心会话之间的命名冲突。

ON COMMIT 是 PostgreSQL 临时表的精髓，它有三个选项，一定要分清：

• ON COMMIT PRESERVE ROWS：事务结束后数据保留，这是默认行为，适用于大多数会话级场景。
• ON COMMIT DELETE ROWS：事务提交时清空数据，适合“一个事务内多步操作共享中间结果”的场景，能避免数据残留给下一个事务造成污染。
• ON COMMIT DROP：事务结束时连表结构一起删除，使用这个选项时，表只能在事务块内创建。它的好处是省去手动 DROP，坏处是如果事务很大、又频繁创建这种临时表，会给系统带来额外开销。

PostgreSQL 也支持 CTAS 的类似写法：

sql复制CREATE TEMP TABLE tmp_goods_rank AS
SELECT 
    goods_id,
    ROW_NUMBER() OVER (ORDER BY sales_amount DESC) AS rank_no
FROM goods_sales_daily
WHERE stat_date = CURRENT_DATE;

CTAS 创建出的临时表同样不会自动带主键和索引，需要后续手动添加。但 PostgreSQL 在 CTAS 方面有一点做得比 MySQL 好：字段的数据类型推导更保守一些，不容易出现字符串被推成 TEXT 的问题。

还有一个实践中的知识点：PostgreSQL 的临时表不会被 autovacuum 自动处理。如果你在高频业务里反复创建和删除大量临时表，垃圾元组可能在系统表里积累，时间长了会拖慢数据库的整体表现。我在批处理任务里遇到过一次系统表膨胀的问题，排查了半天才发现是临时表频繁创建又不清理导致的，所以规范的做法是：用完立刻 DROP，如果任务循环处理频繁，在循环外尽量复用同一张临时表，而不是每轮重建。

2.4 Oracle：全局临时表 GTT 的表结构是永久的

Oracle 的临时表和前面几种数据库差别最大，名字叫 Global Temporary Table（GTT），但这里的 Global 指的是所有会话都可以“看到表结构”，而不是共享数据。每个会话写入的数据，其他会话完全看不见。

创建 GTT 的语法如下：

sql复制CREATE GLOBAL TEMPORARY TABLE gtt_order_stat (
    order_no   VARCHAR2(32),
    product_no VARCHAR2(32),
    total_qty  NUMBER
) ON COMMIT DELETE ROWS;

ON COMMIT DELETE ROWS 表示事务提交时清空数据，适合在事务过程中保存中间状态；如果改成 ON COMMIT PRESERVE ROWS，则数据在会话结束时才被清空，适合跨多个事务、需要在会话范围内反复使用的场景。

GTT 有一个非常容易被新手误解的地方：表结构是永久保存在数据字典里的，和普通的正式表一样需要被创建、可以被 DROP。你反复执行一段事务处理代码，事务提交后表还在，数据却没了，这是正常现象，不是出了 bug。换句话说，Oracle 下你几乎不需要像 MySQL 那样频繁执行 CREATE TEMPORARY TABLE，GTT 通常建一次，长期使用，每次事务自动清理数据，这正是它名字里“全局”的含义。

Oracle 也支持在创建 GTT 时直接填充数据吗？支持的写法是把 CTAS 扩展进来：

sql复制CREATE GLOBAL TEMPORARY TABLE gtt_rank_result
ON COMMIT PRESERVE ROWS
AS
SELECT goods_id, RANK() OVER (ORDER BY sales_amount DESC) AS rank_no
FROM goods_sales_daily;

写成这样比较少见，但也确实可以，表结构根据查询结果自动推导。

谈到 GTT 的另一个使用习惯：如果临时表要参与大量数据加工，GTT 同样可以建索引、收集统计信息。但注意，所有会话共用同一份表结构，如果某个会话里对 GTT 执行了 TRUNCATE，它会同时截断所有会话的数据吗？不会，TRUNCATE 只影响发出命令的会话自己的数据吗？这里要谨慎，官方文档指出 TRUNCATE 一个临时表只会清空当前会话的行，不会影响其他会话的数据。这正是 GTT 的隔离设计。我建议在需要清空数据时，优先使用 DELETE 或 TRUNCATE 而不是 DROP 表再重建，重建 GTT 会影响到所有正在使用它的会话。

2.5 四种数据库临时表核心差异速查

这张表记在心里，跨数据库切换开发时能省掉很多不必要的纠错时间。

3. 一个真实案例：用临时表拆掉三层嵌套的慢 SQL

光讲语法不落地等于白说，我拿一个实际做过的电商订单数据清理场景来复现一遍。这个案例想表达的并不是某个技巧多么神奇，而是说当查询复杂到一定程度时，临时表往往是让问题变简单的最优解。

3.1 背景和表结构：订单明细表里的重复数据

假设有一张订单明细表 order_item，结构大概长这样：

sql复制CREATE TABLE order_item (
    id          BIGINT PRIMARY KEY,
    order_no    VARCHAR(32),
    product_no  VARCHAR(32),
    qty         INT,
    category_id INT,
    create_time DATETIME
);

业务方找到我，说报表里同一个 order_no + product_no 出现了好几条相同记录，怀疑是上游重复导数据导了好几次。要求是：把重复的明细去重，只保留每个 order_no + product_no 组合里 id 最大的那条，并按 product_no 维度统计清洗完成后的总数量。如果按某些查询狂魔的写法，很容易写出这样的嵌套大 SQL：

sql复制SELECT 
    t.product_no,
    SUM(t.qty) AS total_qty
FROM (
    SELECT product_no, qty,
           ROW_NUMBER() OVER (PARTITION BY order_no, product_no ORDER BY id DESC) AS rn
    FROM order_item
) t
WHERE t.rn = 1
GROUP BY t.product_no;

这个查询数据量小的时候还行，如果 order_item 有几千万行，这条 SQL 内部要先做全表排序，再在外层聚合。如果后面还要继续 join 别的表、做多轮条件筛选，一条 SQL 会被撑得很难维护。报表数据加工过程不止一次使用这个去重后的明细，那不如把中间结果先落临时表。

3.2 用临时表分步处理的完整过程

在 MySQL 里，我一般这样写：

sql复制-- 第一步：创建临时表，只保留每个组合里 id 最大的记录
DROP TEMPORARY TABLE IF EXISTS tmp_order_item_dedup;

CREATE TEMPORARY TABLE tmp_order_item_dedup AS
SELECT 
    order_no,
    product_no,
    qty,
    category_id,
    id
FROM (
    SELECT 
        order_no,
        product_no,
        qty,
        category_id,
        id,
        ROW_NUMBER() OVER (PARTITION BY order_no, product_no ORDER BY id DESC) AS rn
    FROM order_item
) t
WHERE t.rn = 1;

-- 第二步：给临时表加上聚合查询必需的索引
ALTER TABLE tmp_order_item_dedup ADD INDEX idx_product (product_no);

-- 第三步：后续所有统计直接基于临时表进行
SELECT product_no, SUM(qty) AS total_qty
FROM tmp_order_item_dedup
GROUP BY product_no;

分步处理之后每一段 SQL 都很短，也很容易读懂。更重要的是，如果在第三步之后我还要按品类继续分组、要 join 商品资料表，都不需要重新扫描整个 order_item，也不需要在一条 SQL 里反复嵌套。中间结果被实体化，后面每一层查询都能直接读它。

3.3 换到 SQL Server 和 PostgreSQL 怎么写

同样的场景，放进 SQL Server 就是临时表加 SELECT INTO：

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

SELECT 
    order_no,
    product_no,
    qty,
    category_id,
    id
INTO #tmp_order_dedup
FROM (
    SELECT 
        order_no,
        product_no,
        qty,
        category_id,
        id,
        ROW_NUMBER() OVER (PARTITION BY order_no, product_no ORDER BY id DESC) AS rn
    FROM order_item
) t
WHERE t.rn = 1;

CREATE INDEX idx_product ON #tmp_order_dedup(product_no);

SELECT product_no, SUM(qty) AS total_qty
FROM #tmp_order_dedup
GROUP BY product_no;

注意 SQL Server 里 SELECT INTO 新表时表名不能带括号，这点和 MySQL CTAS 不太一样。也可以先 CREATE TABLE #tmp，再 INSERT INTO #tmp SELECT ...，那样更灵活，但代码会多几行。

PostgreSQL 的写法几乎和 MySQL 一致：

sql复制CREATE TEMP TABLE tmp_order_item_dedup AS
SELECT 
    order_no,
    product_no,
    qty,
    category_id,
    id
FROM (
    SELECT ...   -- 同上
) t
WHERE t.rn = 1;

CREATE INDEX idx_product ON tmp_order_item_dedup (product_no);

如果你用的是 Oracle GTT，那么表结构要预先创建一次，然后再 INSERT：

sql复制CREATE GLOBAL TEMPORARY TABLE gtt_order_item_dedup (
    order_no    VARCHAR2(32),
    product_no  VARCHAR2(32),
    qty         NUMBER,
    category_id NUMBER,
    id          NUMBER
) ON COMMIT PRESERVE ROWS;

这个案例想说明的是：不管哪种数据库，临时表的本质都是把“复杂问题”切成“简单问题”，让每一段代码都能独立验证。实际做数据清洗的时候，先用窗口函数去掉重复是最稳妥的第一步；但去重之后结果集还要继续参与统计和关联时，临时表就是比子查询更可靠的载体。

4. 长期使用后踩过的坑和排查记录

和临时表打多了交道，自然会遇到一些奇怪的现象。这一章我整理了一些个人经历的典型问题，按“症状—原因—解法”的思路做了一份排查记录，希望你能少走点弯路。

4.1 作用域陷阱：为什么下次打开连接表就不见了

我在给团队做代码审查时，经常看到有人在 MySQL 里创建了临时表，然后第二天或者下一次会话里又继续访问这张表，结果自然是“Table doesn't exist”。原因很简单：MySQL 临时表只属于创建它的那个会话，会话一断开，表就没了。

在 SQL Server 里这个问题更隐蔽。很多用连接池的应用，SqlConnection 调用 Close 之后底层物理连接并没有真正断开，而是回到了连接池里。于是你上次创建的 # 临时表并没有被马上清理。如果连接池把同一条物理连接再次分配给新的 SqlConnection，这个新会话里居然还能看到上一次的临时表。如果业务代码没有显式 DROP，后续逻辑会读到陈旧的中间数据，产生非常难查的间歇性 bug。

我的排查经验是：凡是创建临时表的代码，无论是哪种数据库，都要在同一段逻辑里显式清理。即使数据库本来会自动回收，显式 DROP 永远是一个正确的习惯。在 Oracle 里使用 GTT 时要额外注意，有些平台建模工具导出结构时会把 GTT 当成正式表一起备份和发布，导致你明明只是想临时用一下，结果生产环境被创建了一张带权限和依赖的永久对象。

4.2 性能表现：建了索引还慢，多半是统计信息在作怪

临时表不是建完就能飞，性能问题需要单独排查。首先，大量数据入库后如果你不建索引，全表扫描是大概率事件。尤其是后续需要对临时表做 join、group by、filter 时，索引的影响非常明显。

但建了索引性能也不一定好，因为许多数据库对临时表的统计信息收集不像正式表那么积极。比如 SQL Server，临时表数据量如果很大，而优化器拿到的统计信息还是表刚创建时的空表统计，它可能错误地选择 Nested Loop 甚至把临时表当成只有一行来处理。遇到这种情况，直接手动更新统计信息：

sql复制UPDATE STATISTICS #tmp_order_item_dedup;

PostgreSQL 同样有这个问题。临时表创建时是空的，你往里插入大量数据后，如果没有触发 analyze，查询规划器很可能按 0 行估算，选出来的执行计划会非常奇怪。更麻烦的是 PostgreSQL 默认不会对临时表跑 autovacuum，所以依赖自动收集基本不可靠。我在写批处理脚本时，会习惯性地在大量插入完成后加一句：

sql复制ANALYZE temp 表名;

这句做不做，执行计划的差异可能是一个数量级的差别。

4.3 临时表、表变量、CTE 到底怎么选

这是另一个高频问题。很多人问我：既然临时表这么好用，为什么有些场景团队规范不让我们用临时表，要用 CTE？因为工具没有绝对好坏，只有适合的场景。

CTE（Common Table Expression）是紧随 SELECT 关键字之后的临时命名查询，它只在当前这条 SQL 语句内有效，本质上更接近“视图”而不是“表”。它适合做单条 SQL 的可读性拆分和递归查询，但因为不可跨语句复用，你没办法在第二步继续用它。如果你写的 SQL 只执行一次，逻辑又集中在一条语句里，CTE 确实比临时表轻巧很多。

表变量则是 SQL Server 独有的概念，用 DECLARE @xxx TABLE 声明。它通常存储在内存中，事务回滚不会影响表变量，统计信息也很有限。如果数据量只有几十行几百行，表变量很好用；但如果数据量过万，你会发现查询速度还不如临时表。原因是优化器默认表变量行数极少，无法做准确的成本估算。

我按自己习惯整理了一个选择参考：

如果你拿不准，一个直接的经验就是：中间结果集超过几千行，并且还要继续 join 或者 group by，那么不要犹豫，临时表。不到几百行的小量数据，且只在这条 SQL 内有效，那用 CTE 能省很多事。

4.4 别拿临时表干持久化的活

最后一个提醒，和权限、规范有关。我遇到过一种比较尴尬的场景：某临时表数据量巨大，业务方想跨任务复用，于是每天在报表程序里创建临时表，一直不删，最后数据库里堆了大量残留会话。

临时表的本意是“短命”，不要把临时表当作缓存表长时间保留。跨会话、跨任务需要共享数据时，应该设计成正式表并带好业务日期分区或任务标识，任务结束按条件清理。这不仅是性能问题，更是数据血缘和管理规范问题。否则某天核心表误删了，你连数据怎么算出来的都说不清。

我个人的体感是：熟练使用临时表，是区分“SQL 初学者”和“能写复杂数据加工逻辑的人”的一道分水岭。它不复杂，但牵涉到每种数据库的底层生命周期机制；它很好用，但也容易在连接池、统计信息、事务提交行为的细节上给人挖坑。把这篇文章里提到的语法和注意点对照自己常用的数据库过一遍，再回来看你以前那些冗长的嵌套 SQL，大概率会有种“原来还能这么写”的感觉。