MySQL中UNION与UNION ALL性能对比：别再被“保险”迷惑，差距远超预期
先给出核心结论：UNION ALL 的性能通常比 UNION 高出不止一个数量级。原因在于，UNION 在合并结果集后会自动触发去重操作，这往往伴随着隐式排序，进而产生临时表和文件排序。而 UNION ALL 则直接将各个子查询的结果拼接在一起，完全不干预数据内容。从执行计划视角来看，UNION 等价于 UNION ALL 再套一层 DISTINCT，这直接导致了 Using temporary 和 Using filesort 的出现，I/O 和 CPU 开销自然显著攀升。
UNION ALL 速度远超 UNION：无需去重，性能飙升
性能差距究竟有多大？举例说明：两个各返回 50 万行的子查询，用 UNION ALL 可能在 200 毫秒内流式返回，数据像流水般从数据库吐出。而 UNION 则会卡在 Using temporary; Using filesort 上，耗时数秒甚至直接导致内存溢出（OOM）。
如果你的查询出现以下情况，基本可以断定是 UNION 的去重逻辑在作祟：
- 执行计划里出现了
Using temporary或Using filesort - 查询响应时间随结果集增长呈现非线性飙升
- 临时表空间（
tmp_table_size/max_heap_table_size）被频繁打满
UNION 可能悄然改变结果行数与顺序，需警惕
这一特性非常隐蔽，但潜在影响不容小觑。只要任意两行在所有列上完全相等，UNION 就会毫不留情地剔除一个。哪怕这两行来自不同业务表——比如“正式员工”和“外包人员”里都叫“张三”、部门也相同——也会被当作重复行过滤掉。这不是 bug，这就是 UNION 的设计行为。
更令人头疼的是顺序问题。UNION 的去重过程，在 MySQL 8.0 以前尤为明显，会伴随隐式排序，导致最终结果的顺序完全不可控。而 UNION ALL 至少能忠实地保持各子查询的原始输出顺序——除非你显式加上 ORDER BY。
来看几个典型应用场景，就能清楚何时该用哪个：
- 合并按天分表的日志（如
log_20260501,log_20260502……）—— 数据天然不重复，直接用UNION ALL - 跨库汇总用户注册数 —— 各库 ID 独立，不可能重复，用
UNION ALL - 补全缺失维度值（如左连接后用
UNION ALL加默认分类）—— 明确要保留所有行，用UNION ALL
列对齐、类型兼容及 ORDER BY 写法需严格遵守规则
无论是 UNION 还是 UNION ALL，它们都不是“智能拼接”，只认位置，不认字段名。下面这些写法，MySQL 都会直接报错：
SELECT name, id FROM t1 UNION SELECT id, name FROM t2—— 列顺序错乱，第一列拼的是t1.name和t2.id，语义完全混乱SELECT created_at FROM orders UNION SELECT order_time FROM history—— 类型不兼容，如DATETIME和TIMESTAMP在某些版本会直接报错SELECT x FROM a ORDER BY x LIMIT 10 UNION SELECT y FROM b ORDER BY y LIMIT 10—— 语法非法，MySQL 会抛出ERROR 1221
正确做法是什么？
- 统一用
CAST()或CONVERT(... USING utf8mb4)显式转换数据类型 - 所有子查询的列数、顺序、别名必须完全一致。例如，统一写成
SELECT id AS uid, name AS fullname FROM ... ORDER BY只能放在整个查询的最后，并且只能引用列名或位置序号：... UNION ALL ... ORDER BY fullname- 如果希望每个子查询各自取 top N，则需要包一层子查询：
(SELECT ... ORDER BY x LIMIT 10) UNION ALL (SELECT ... ORDER BY y LIMIT 10)
何时真正应该使用 UNION？理性判断而非凭感觉
只有当以下条件全部满足时，才值得考虑 UNION：
- 业务逻辑明确要求结果中每行全局唯一（比如合并多个来源的用户 ID，且 ID 是主键）
- 你无法在子查询里通过
WHERE或JOIN提前排重 - 数据量不大，或已经确认去重开销完全可控（如总行数在几千以内）
如果只是“怕有重复所以保险起见”，反而容易埋下隐患。例如某天上游数据逻辑变更，导致本不该去重的行被意外合并，这种问题回溯起来非常困难。更稳妥的做法是：先用 UNION ALL 查出全量数据，再用 SELECT DISTINCT 包一层。虽然性能可能稍差，但语义清晰、可调试，出了问题也容易定位。
最后，还有一个极易被忽略的细节：即使两个表结构一模一样，UNION 也会把 NULL 和 NULL 当作相等去重。但在很多业务场景里，NULL 的语义是“未知”，而非“相同”。这一点在统计类查询中，很容易引发数据偏差，需要格外警惕。
