MySQL中UNION操作推荐用UNION ALL的原因

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 的语义是“未知”，而非“相同”。这一点在统计类查询中，很容易引发数据偏差，需要格外警惕。