1. SQL UNION语句基础解析

UNION是SQL中用于合并多个SELECT查询结果集的操作符。我第一次接触这个语法是在处理多表数据汇总需求时，当时需要将销售部门和生产部门的报表合并输出。与简单的JOIN操作不同，UNION更像是垂直堆叠数据而非水平连接。

1.1 UNION的核心特性

UNION操作有几个关键特性需要特别注意：

• 参与合并的SELECT语句必须具有相同数量的列
• 对应列的数据类型必须兼容（或可隐式转换）
• 最终结果集的列名取自第一个SELECT语句
• 默认情况下UNION会去除重复行（相当于DISTINCT操作）

实际工作中最常见的错误就是列数不匹配。上周我还遇到一个案例：开发人员尝试合并一个5列和6列的查询，系统直接抛出"All queries combined using a UNION must have an equal number of expressions"错误。

1.2 基本语法结构

标准UNION语法如下：

SELECT column1, column2 FROM table1 UNION SELECT column1, column2 FROM table2;

这里有个实用技巧：当列名不同时，可以使用别名统一输出：

SELECT product_id AS id, product_name AS name FROM products UNION SELECT sku_id AS id, sku_desc AS name FROM inventory;

2. UNION与UNION ALL的深度对比

2.1 去重机制详解

UNION和UNION ALL最大的区别在于重复数据处理。我做过一个性能测试：在100万行数据上执行UNION比UNION ALL慢约40%，因为UNION需要执行以下额外步骤：

1. 创建临时结果集
2. 对每行数据计算哈希值
3. 维护哈希表检测重复
4. 最后排序输出

重要提示：当确定数据源没有重复或需要保留重复时，务必使用UNION ALL以获得最佳性能

2.2 实际应用场景选择

根据我的经验，这些情况适合用UNION：

• 合并不同来源但可能有重复的数据（如多分公司销售记录）
• 需要自动去重的报表生成

而这些情况应该用UNION ALL：

• 合并绝对不会有重复的查询（如不同年份的数据）
• 需要保留所有记录的审计日志
• 性能敏感的ETL过程

3. 高级UNION技巧与应用

3.1 多表复杂合并实战

我最近处理的一个电商项目需要合并三种数据源：

-- 合并订单、退货单和换货单 SELECT order_id, amount, 'order' AS type FROM orders UNION ALL SELECT return_id, refund_amount, 'return' FROM returns UNION ALL SELECT exchange_id,差价金额, 'exchange' FROM exchanges;

这里有几个技巧值得分享：

1. 添加类型标识列方便后续处理
2. 使用UNION ALL避免不必要的去重开销
3. 对金额字段使用统一名称（第二个查询用refund_amount别名）

3.2 与ORDER BY的配合使用

UNION后的ORDER BY子句作用于最终结果集。常见误区是试图单独排序每个子查询：

-- 错误写法（某些数据库可能支持但不标准） SELECT * FROM table1 ORDER BY col1 UNION SELECT * FROM table2; -- 正确写法 SELECT * FROM table1 UNION SELECT * FROM table2 ORDER BY col1;

在MySQL中如果需要对不同子查询使用不同排序，可以这样处理：

(SELECT * FROM table1 ORDER BY col1 LIMIT 10) UNION (SELECT * FROM table2 ORDER BY col2 LIMIT 10);

4. 性能优化与常见问题

4.1 索引优化策略

针对UNION查询的索引设计有特殊要求。我建议：

1. 为每个子查询的WHERE条件单独创建索引
2. 考虑使用覆盖索引减少IO
3. 对大表UNION可尝试先过滤再合并

示例优化前后对比：

-- 优化前（全表扫描） SELECT * FROM large_table1 UNION SELECT * FROM large_table2; -- 优化后（索引扫描） SELECT * FROM large_table1 WHERE create_date > '2023-01-01' UNION SELECT * FROM large_table2 WHERE status = 'active';

4.2 典型错误排查指南

根据我处理过的支持案例，整理出UNION常见错误：

5. 特殊场景应用案例

5.1 分库分表数据汇总

在分布式系统中，UNION常用于合并分片数据。最近我帮客户实现的方案：

-- 合并2023年按月分表的订单数据 SELECT * FROM orders_202301 UNION ALL SELECT * FROM orders_202302 ... UNION ALL SELECT * FROM orders_202312;

关键点：

1. 确保所有分表结构完全一致
2. 使用UNION ALL避免去重开销
3. 考虑使用视图封装简化查询

5.2 动态SQL生成

在报表系统中，我们经常需要动态构建UNION查询。这是我在BI工具中实现的PHP示例：

$unions = []; foreach ($branches as $branch) { $unions[] = "SELECT * FROM {$branch}_sales"; } $sql = implode(" UNION ALL ", $unions);

6. 与其他SQL子句的配合

6.1 与GROUP BY的组合

UNION结果可以进一步聚合。一个销售分析案例：

SELECT region, SUM(amount) FROM ( SELECT region, amount FROM online_orders UNION ALL SELECT store_region, amount FROM offline_orders ) combined GROUP BY region;

6.2 在CTE中的使用

WITH子句可以使UNION查询更清晰。我偏好的写法：

WITH online AS ( SELECT product_id, online_price FROM products ), offline AS ( SELECT product_id, offline_price FROM stores ) SELECT * FROM online UNION SELECT * FROM offline;

7. 各数据库实现差异

7.1 MySQL特别注意事项

MySQL的UNION有一些独特行为：

1. 8.0版本前不支持UNION中的LIMIT子句
2. 结果集排序可能不稳定
3. 临时表可能使用MEMORY引擎

7.2 SQL Server的特性

SQL Server提供了一些扩展功能：

-- 使用TOP限制每个子查询 SELECT TOP 10 * FROM table1 UNION SELECT TOP 10 * FROM table2; -- 支持UNION到临时表 SELECT * INTO #temp FROM table1 UNION SELECT * FROM table2;

8. 安全注意事项

8.1 SQL注入防范

动态构建UNION查询时要特别注意注入风险。安全做法：

# Python安全示例 params = [] queries = [] for table in user_input: queries.append("SELECT * FROM %s WHERE 1=1") params.append(table) safe_sql = " UNION ALL ".join(queries) cursor.execute(safe_sql, params)

8.2 权限管理建议

执行UNION查询需要所有子查询表的SELECT权限。最佳实践是：

1. 创建专门的只读角色
2. 按需授予最小权限集
3. 对生产环境使用视图封装

9. 调试技巧与工具

9.1 执行计划分析

理解UNION查询的执行计划很重要。关键点：

• 查找"Temp Table"操作
• 注意"Union"操作符
• 检查每个子查询的成本

9.2 分步调试方法

复杂UNION查询建议分步验证：

1. 单独执行每个子查询
2. 两两合并测试
3. 逐步添加更多UNION
4. 最后添加排序/分组

10. 替代方案考量

10.1 与JOIN的比较

JOIN是水平连接，UNION是垂直堆叠。选择依据：

• 需要扩展列数用JOIN
• 需要增加行数用UNION
• 多对多关系用JOIN
• 相同结构数据合并用UNION

10.2 临时表方案

对于极复杂的UNION，可考虑：

-- 创建临时表存储中间结果 CREATE TEMPORARY TABLE temp_result AS SELECT * FROM table1; INSERT INTO temp_result SELECT * FROM table2; -- 最终处理 SELECT * FROM temp_result;

在实际项目中，我通常会在这些技术方案间做选择：

1. 简单合并用UNION
2. 需要中间处理用CTE
3. 非常复杂时用临时表
4. 频繁使用则创建物化视图