SQL中UNION与UNION ALL的核心区别与性能优化

1. 理解UNION与UNION ALL的本质区别

在SQL查询中，UNION和UNION ALL都是用于合并多个SELECT语句结果集的操作符，但它们的处理逻辑存在关键差异。我们先从一个实际案例入手：假设我们需要合并两个部门的员工名单，销售部有5人（含1名重复员工），技术部有7人（含2名与销售部重复的员工）。

当使用UNION ALL合并时：

sql复制SELECT name FROM sales_dept
UNION ALL
SELECT name FROM tech_dept;

结果集会包含所有12条记录（5+7），完全保留原始数据，包括重复项。这种操作就像把两个Excel表格简单堆叠在一起，不做任何去重处理。

而使用UNION时：

sql复制SELECT name FROM sales_dept
UNION
SELECT name FROM tech_dept;

数据库会先合并结果，然后执行额外的去重操作。以上述案例为例，最终可能只返回10条记录（去除2个重复项）。这个过程类似于在Excel中使用"删除重复项"功能。

关键区别：UNION ALL保留所有记录（含重复），UNION会自动去除完全相同的行。这个差异直接影响查询性能和结果准确性。

2. 底层执行机制深度解析

2.1 UNION ALL的工作流程

1. 顺序执行每个SELECT语句
2. 将每个结果集按顺序叠加
3. 直接返回合并后的结果
   整个过程不需要临时表或排序操作，时间复杂度是O(n)，n为总记录数。

2.2 UNION的标准实现步骤

1. 创建临时结果表
2. 执行所有SELECT语句并将结果插入临时表
3. 对临时表进行排序（或使用哈希算法）
4. 遍历排序后的结果，去除相邻重复项
5. 返回最终结果
   这个过程的平均时间复杂度是O(n log n)，因为涉及排序操作。

2.3 性能对比实测数据

通过EXPLAIN分析相同查询：

• UNION ALL查询类型显示"SIMPLE"
• UNION会显示"TEMPORARY"和"FILESORT"
  在百万级数据测试中：
• UNION ALL耗时约120ms
• UNION耗时约980ms
  差异主要来自磁盘I/O和CPU计算开销。

3. 实战应用场景与选择策略

3.1 必须使用UNION ALL的场景

1. 日志合并分析：需要保留所有原始记录

   sql复制-- 合并多台服务器的错误日志
   SELECT * FROM server1_logs WHERE level='ERROR'
   UNION ALL
   SELECT * FROM server2_logs WHERE level='ERROR'
   

2. 增量数据统计：确保计数准确

   sql复制-- 计算总销售额（允许重复交易）
   SELECT SUM(amount) FROM (
     SELECT amount FROM online_orders
     UNION ALL
     SELECT amount FROM offline_orders
   ) combined
   

3. 明确需要重复数据的业务场景

3.2 应该使用UNION的场景

1. 生成唯一值列表：

   sql复制-- 获取所有不重复的城市列表
   SELECT city FROM customers
   UNION
   SELECT city FROM suppliers
   

2. 数据清洗后的合并：

   sql复制-- 合并已去重的用户标签
   SELECT DISTINCT tag FROM user_tags_v1
   UNION
   SELECT DISTINCT tag FROM user_tags_v2
   

3. 需要排除重复结果的报表生成

3.3 高级使用技巧

1. 混合使用实现性能优化：

   sql复制-- 先各自去重再合并
   SELECT DISTINCT col1 FROM table1
   UNION ALL
   SELECT DISTINCT col1 FROM table2
   

2. 配合GROUP BY替代UNION：

   sql复制-- 等效但可能更高效的写法
   SELECT col1 FROM (
     SELECT col1 FROM table1
     UNION ALL
     SELECT col1 FROM table2
   ) temp GROUP BY col1
   

4. 常见问题与性能优化方案

4.1 数据类型兼容性问题

当合并不同数据类型的列时：

sql复制-- 错误示例
SELECT text_column FROM table1
UNION
SELECT numeric_column FROM table2

解决方案：

1. 显式类型转换：

   sql复制SELECT CAST(text_column AS CHAR) FROM table1
   UNION
   SELECT CAST(numeric_column AS CHAR) FROM table2
   

2. 使用COALESCE处理NULL值

4.2 排序与LIMIT的配合使用

错误用法：

sql复制-- 错误：仅对最后一个查询排序
SELECT * FROM table1
UNION
SELECT * FROM table2
ORDER BY column1 LIMIT 10

正确做法：

sql复制-- 对合并结果排序
(SELECT * FROM table1)
UNION
(SELECT * FROM table2)
ORDER BY column1 LIMIT 10

4.3 索引优化建议

1. 为UNION涉及的列建立覆盖索引
2. 对UNION ALL的大表查询添加WHERE条件限制
3. 考虑使用物化视图预计算UNION结果

5. 深度优化：UNION执行计划调优

5.1 使用EXPLAIN分析

重点关注：

• "Using temporary"表示创建临时表
• "Using filesort"表示排序操作
  优化目标：尽可能消除这两个额外操作

5.2 分区表UNION优化

当合并分区表时：

sql复制-- 优化前
SELECT * FROM orders_2023
UNION
SELECT * FROM orders_2022

-- 优化后（直接查询分区视图）
SELECT * FROM all_orders
WHERE year IN (2022, 2023)

5.3 分布式数据库特殊处理

在分片环境中：

1. 优先在各节点执行过滤
2. 在协调节点合并结果
3. 设置合适的UNION并行度参数

6. 替代方案评估

6.1 JOIN与UNION的选择

需要横向扩展时用UNION：

sql复制-- 纵向合并不同查询结果
SELECT product_id FROM inventory
UNION
SELECT item_id FROM warehouse

需要关联查询时用JOIN：

sql复制-- 横向关联表数据
SELECT * FROM orders
JOIN customers ON orders.cust_id = customers.id

6.2 临时表方案

对于复杂UNION操作：

sql复制-- 分步处理提高可读性
CREATE TEMPORARY TABLE temp_results
SELECT col1 FROM table1 WHERE condition;

INSERT INTO temp_results
SELECT col1 FROM table2 WHERE condition;

-- 最终处理
SELECT DISTINCT * FROM temp_results;

7. 各数据库实现差异

7.1 MySQL/MariaDB特性

1. 默认对UNION结果排序
2. 8.0+版本支持LIMIT下推优化
3. 可通过设置sql_mode控制严格性

7.2 PostgreSQL增强功能

1. 支持UNION/INTERSECT/EXCEPT组合
2. 提供更高效的哈希去重算法
3. 允许在UNION中使用窗口函数

7.3 Oracle特殊语法

1. 支持UNION ALL的并行提示

   sql复制SELECT /*+ PARALLEL(4) */ col1 FROM tab1
   UNION ALL
   SELECT /*+ PARALLEL(4) */ col1 FROM tab2
   

2. 提供UNION的物化视图支持

8. 实际业务场景案例

8.1 电商平台订单合并

sql复制-- 合并正常订单与退货订单统计
SELECT 
  'normal' AS order_type,
  COUNT(*) AS count 
FROM orders
WHERE status = 'completed'

UNION ALL

SELECT 
  'returned' AS order_type,
  COUNT(*) AS count 
FROM returns
WHERE processed = true

8.2 多数据源用户整合

sql复制-- 合并各渠道用户(去重)
SELECT 
  email,
  MAX(register_date) AS last_date
FROM (
  SELECT email, reg_date AS register_date FROM web_users
  UNION
  SELECT email, create_time FROM app_users
  UNION
  SELECT email, signup_date FROM wechat_users
) combined
GROUP BY email

8.3 时序数据分片查询

sql复制-- 查询最近30天日志（按天分表）
SELECT * FROM logs_20230801 WHERE level='ERROR'
UNION ALL
SELECT * FROM logs_20230802 WHERE level='ERROR'
-- ...其余28天表
ORDER BY timestamp DESC

9. 最佳实践总结

1. 默认优先考虑UNION ALL，除非明确需要去重
2. 大数据量时考虑分阶段处理：
   • 先过滤再合并
   • 先各自去重再UNION ALL
3. 监控UNION查询的执行计划
4. 为频繁使用的UNION查询创建视图
5. 在ETL过程中考虑使用临时表替代复杂UNION

在数据仓库建设项目中，曾处理过一个典型案例：需要合并5个业务系统的用户表，初始使用UNION导致查询耗时超过15分钟。改为以下方案后降至23秒：

sql复制-- 优化方案
CREATE TABLE temp_users AS
SELECT DISTINCT user_id FROM system1.users WHERE is_active=1;

INSERT INTO temp_users
SELECT DISTINCT user_id FROM system2.customers WHERE status='active';

-- ...其他系统

-- 最终去重
SELECT user_id FROM temp_users GROUP BY user_id;

关键是要理解UNION和UNION ALL不是简单的语法差异，而是对应着完全不同的执行策略和资源消耗模式。根据业务需求合理选择，往往能获得数量级的性能提升。