UNION比UNION ALL慢的根本原因是其强制执行临时表创建、全量排序（Using filesort）、逐行去重及可能的磁盘I/O，而UNION ALL仅为流式拼接；实测100万行时UNION耗时是UNION ALL的11倍以上。
UNION 比 UNION ALL 慢，根本原因不是“多做了去重”，而是它强制触发了一整套资源密集型操作：建临时表、全量排序、逐行比对、可能写磁盘——而 UNION ALL 就是把两块结果直接接起来，不加任何中间处理。
UNION 实际执行的是 UNION ALL + DISTINCT + 隐式 ORDER BY
很多人以为 UNION 是“合并后挑重”，其实数据库引擎不会这么聪明。它必须先把所有子查询结果一次性拉进临时结构（内存或磁盘），再整体做 DISTINCT；而 DISTINCT 在绝大多数引擎里默认依赖排序实现（MySQL 用 Using filesort，PostgreSQL 用 Sort + Unique）。哪怕你没写 ORDER BY，UNION 也会按第一列升序排——这不是优化，是强制行为。
常见错误现象：
-
EXPLAIN中出现Using temporary和Using filesort - 查询过程中
tmp_table_size被打爆，临时表落到磁盘，I/O 突增 - 原本能走索引的
WHERE或JOIN，因排序破坏了原始顺序，被迫退化为全表扫描
性能差距随数据量非线性放大，100 万行时慢 11 倍以上
这不是常数倍开销，而是算法复杂度差异：UNION ALL 是 O(n)，UNION 接近 O(n log n)。实测数据（MySQL 8.0，SSD）：
- 10 万行：
UNION ALL82ms，UNION620ms（7.5 倍） - 100 万行：
UNION ALL810ms，UNION9200ms（11 倍以上）
瓶颈不在 CPU，而在：
- 临时表写入 SSD 的延迟
- 排序阶段大量内存比较（尤其多列、大字段如
TEXT） - 内存不足时换出到磁盘，触发 swap
你以为“没重复”就安全？NULL 和隐式转换会偷偷搞事情
即使你确信两个子查询结果天然不重叠，UNION 仍照常跑全套流程。更危险的是：你以为没重复，其实有。
-
NULL = NULL在UNION中被判定为相等，会被去重；UNION ALL则保留全部NULL - 第一条语句返回
NOT NULL VARCHAR(50)，第二条返回NULL，某些 MySQL 版本在严格模式下直接报错，不是慢，是根本执行不了 - 隐式类型转换失败（如
INT和VARCHAR混用）同样会让两者都报错，别指望ALL更宽容
嵌套查询里用 UNION，优化器大概率失控
当 UNION 出现在子查询中（比如 WHERE id IN (SELECT ... UNION SELECT ...)），优化器很难估算中间结果规模，容易放弃使用索引，转而走全表扫描或临时表。
可选替代方案：
- 提前物化：用
CREATE TEMPORARY TABLE或 CTE（MySQL 8.0+）把结果存下来再 JOIN - 改写为
EXISTS或LEFT JOIN ... ON ... OR ...，避免生成中间集合 - 如果必须去重，把
DISTINCT下推到子查询内部（如SELECT DISTINCT id FROM a），而不是靠 UNION 全局收敛
最常被忽略的一点：UNION 的隐式排序不可靠，UNION ALL 的顺序完全不可控——外层不加 ORDER BY，结果顺序在不同版本、不同执行路径下都可能变。线上分页或前端渲染依赖顺序时，这比性能问题更容易引发事故。
