为什么尽量使用 UNION ALL 而不是 UNION?
在 SQL 中,UNION 和 UNION ALL 都用于合并两个或多个查询的结果集。区别在于:
UNION:对合并后的结果集进行隐式去重 (相当于SELECT DISTINCT)。UNION ALL:简单地将所有结果拼接在一起,保留重复行。
核心建议 :除非你明确需要 去除重复行,否则应该使用 UNION ALL。主要原因如下:
1. 性能差异巨大
-
UNION的去重操作需要数据库执行额外的步骤:- 排序整个结果集(通常基于所有列),然后扫描去重;
- 或构建哈希表来检测重复项。
- 这需要额外的内存、CPU 和临时存储空间,尤其当结果集很大时,代价极高。
-
UNION ALL只是简单地将多个结果集串联起来,数据库直接返回,没有任何去重开销。
实测对比:假设两个子查询各返回 100 万行,且几乎没有重复:
UNION ALL几乎瞬间返回(200 万行流式传输)。UNION可能需要几秒甚至几十秒去完成排序去重,还消耗大量临时空间。
2. 避免意外的结果丢失
- 如果业务逻辑中允许或期望重复行 ,使用
UNION会错误地合并重复,导致结果行数变少,可能隐藏数据问题。 - 例如:统计各部门员工和兼职人员的名单,同一个员工可能在两个子查询中都出现(既是正式员工又是兼职),使用
UNION会只显示一次,导致统计不准确。
正确做法 :只有当你明确知道 两个子查询的结果集不可能有重复,或者你主动需要消除重复 时,才使用 UNION。
3. 保留原始数据的语义
UNION ALL保持子查询的原始行顺序(如果数据库不额外排序),结果更可预测。UNION由于要去重,通常会打乱顺序(除非外加ORDER BY)。
4. 更好的并行和流式处理
- 很多数据库可以并行执行
UNION ALL的各分支,并将结果直接返回给客户端,无需中间阻塞。 UNION必须收集所有子查询的结果,完成去重后才能输出第一行,增加了延迟。
什么时候使用 UNION?
只有在必须消除重复行 ,且你无法在业务层或通过 WHERE 条件提前去重时,才使用 UNION。例如:
- 合并来自不同表的用户 ID,要求全局唯一。
- 从多个历史分区中查询,可能产生相同的记录,但业务要求唯一。
即便如此,也可以考虑用 UNION ALL + SELECT DISTINCT 外层包装(但通常效率更低)。
示例对比
sql
-- 子查询1:返回 [1,2]
SELECT id FROM A WHERE type='X'
UNION
-- 子查询2:返回 [2,3]
SELECT id FROM B WHERE type='Y';
-- 结果:[1,2,3] (2 被去重)
-- 使用 UNION ALL
SELECT id FROM A WHERE type='X'
UNION ALL
SELECT id FROM B WHERE type='Y';
-- 结果:[1,2,2,3] (保留重复)
总结
| 特性 | UNION ALL |
UNION |
|---|---|---|
| 去重 | 否 | 是 |
| 性能 | 快(无额外操作) | 慢(排序/哈希去重) |
| 内存/临时表 | 低 | 高 |
| 适用场景 | 默认选择,除非必须去重 | 明确需要全局唯一行 |
最佳实践:
- 默认写
UNION ALL。 - 如果你写了
UNION,请注释说明为什么需要去重。 - 避免在生产查询中无意识地使用
UNION,否则随着数据增长,性能会急剧下降。