为什么MySQL执行Union操作时必然会产生内部临时表？-mysql教程-PHP中文网

union在mysql中默认强制使用临时表实现去重，而union all直接流式拼接结果、不建表不加锁；能否替换取决于业务是否真需去重，若无需则应优先用union all。

为什么mysql执行union操作时必然会产生内部临时表？

UNION 操作在 MySQL 中不是“必然”产生内部临时表，但绝大多数常见场景下确实会触发——关键在于它必须实现去重语义，而 MySQL 当前实现（截至 2026 年）把去重逻辑绑定在临时表结构上。

下面分几个实际开发中常遇到的问题点讲清楚：

UNION 去重依赖临时表主键约束

MySQL 实现 UNION 的方式是：先建一个内存临时表，字段与结果集对齐，并把首列（或所有列）设为唯一约束（类似 PRIMARY KEY 或 UNIQUE）。后续每个子查询的结果行都尝试 INSERT IGNORE 进该表——靠唯一性报错跳过重复行。这个机制天然需要可写、可查、带索引的中间存储，也就是临时表。

即使两个子查询都只读、无锁、走索引，UNION 自身仍要执行插入/校验动作 → 必然触发 Using temporary
EXPLAIN 输出里第三行（或最后一步）出现 Using temporary 就是这个阶段
如果结果列含 TEXT/BLOB 或总宽超 tmp_table_size，会立刻落盘成 MyISAM 临时表，锁和 I/O 开销陡增

UNION ALL 为什么能绕过临时表

UNION ALL 不做任何行级比对，MySQL 直接将各子查询结果流式发给客户端。执行计划里看不到 Using temporary，也没有隐式 INSERT 动作。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

每个子查询独立调度，InnoDB 可并行扫描（取决于隔离级别和 MVCC 状态）
不创建临时表 → 避免了 LOCK_X 对临时表的持有，也杜绝落盘风险
注意：UNION ALL 本身不保证顺序，若需排序，ORDER BY 必须显式写在最外层，且此时可能再次触发临时表（用于排序）

哪些情况看似用 UNION，其实根本不需要临时表

很多业务误以为必须用 UNION，但数据本身已天然无交集，去重纯属冗余。

子查询用互斥条件过滤：如 SELECT * FROM t WHERE status = 1 UNION SELECT * FROM t WHERE status = 2 → 可直接换 UNION ALL
子查询含 GROUP BY 或主键 SELECT id, COUNT(*) ... GROUP BY id → 结果天然唯一，UNION 的去重毫无意义
外层已加 DISTINCT 或应用层做了 dedup → 内层 UNION 属于双重去重，应删掉或改 UNION ALL

想保留去重但避开中间临时表膨胀？试试下推 DISTINCT

如果真需要去重，又担心 UNION 在中间阶段就建大临时表，可以把去重逻辑收束到最后一步：

SELECT DISTINCT * FROM (
  SELECT id, name FROM t1 WHERE ...
  UNION ALL
  SELECT id, name FROM t2 WHERE ...
) AS t;

这样只有最终合并后的结果集参与去重，避免子查询结果反复写入/校验临时表。前提是子查询本身不带 ORDER BY / LIMIT / 聚合等会强制提前建临时表的操作。

真正容易被忽略的是：哪怕你把 UNION 换成 UNION ALL，只要子查询里有 GROUP BY 或 ORDER BY，依然可能各自触发临时表——UNION 本身只是其中一环，别让它背锅。