一、问题背景：为什么UNION优化如此重大？

在数据库查询优化中，UNION操作是一个常常被忽视但极其重大的性能关键点。许多开发者习惯性地使用UNION而不知其潜在的性能代价，直到面临慢查询和系统瓶颈时才追悔莫及。本文将通过系统化的分析和实战案例，深入探讨UNION查询的优化策略。

二、UNION与UNION ALL的核心区别

底层机制对比

• UNION：执行去重操作，需要额外的排序/哈希和重复数据消除步骤
• UNION ALL：简单的结果集拼接，无去重开销

性能影响分析

-- 性能差异示例
SELECT id, name FROM table1 
UNION
SELECT id, name FROM table2; -- 需要去重，性能较低

SELECT id, name FROM table1 
UNION ALL
SELECT id, name FROM table2; -- 直接拼接，性能更高

三、UNION查询的六大优化策略

1. 优先使用UNION ALL

适用场景：当业务逻辑不要求去重或已知结果集无重复时

-- 错误示例：不必要的去重
SELECT user_id FROM orders_2023
UNION
SELECT user_id FROM orders_2024;

-- 优化示例：使用UNION ALL
SELECT user_id FROM orders_2023
UNION ALL
SELECT user_id FROM orders_2024;

2. 预先数据过滤

原则：在子查询中尽可能早地过滤数据，减少UNION操作的数据量

-- 错误示例：先UNION后过滤
SELECT * FROM (
    SELECT * FROM table1
    UNION ALL
    SELECT * FROM table2
) AS tmp WHERE condition = true;

-- 优化示例：先过滤后UNION
SELECT * FROM table1 WHERE condition = true
UNION ALL
SELECT * FROM table2 WHERE condition = true;

3. 避免子查询排序

问题：在子查询中使用ORDER BY会导致性能下降

-- 错误示例：子查询排序
(SELECT * FROM table1 ORDER BY col1)
UNION ALL
(SELECT * FROM table2 ORDER BY col2);

-- 优化示例：最终统一排序
SELECT * FROM table1
UNION ALL
SELECT * FROM table2
ORDER BY final_column;

4. 限制返回字段

优化点：只选择必要的字段，减少去重时的比较开销

-- 错误示例：返回过多字段
SELECT * FROM table1
UNION
SELECT * FROM table2;

-- 优化示例：准确选择字段
SELECT id, name, status FROM table1
UNION ALL
SELECT id, name, status FROM table2;

5. 使用临时表处理复杂UNION

适用场景：多层嵌套或复杂UNION查询

-- 创建临时表存储中间结果
CREATE TEMPORARY TABLE temp_results AS
SELECT col1, col2 FROM table1 WHERE condition;

-- 使用临时表进行UNION
SELECT * FROM temp_results
UNION ALL
SELECT col1, col2 FROM table2 WHERE condition;

6. 思考替代方案

架构级优化：

• 使用分区表替代频繁的UNION操作
• 通过物化视图预聚合数据
• 采用联合查询优化器提示

四、实战优化案例

案例背景

订单报表查询，需要合并2023年和2024年的订单数据，原始查询需要15秒。

原始低效SQL：

SELECT order_id, user_id, amount, status 
FROM orders_2023
UNION
SELECT order_id, user_id, amount, status 
FROM orders_2024
WHERE amount > 1000
ORDER BY order_date DESC;

问题分析：

1. 不必要的UNION去重操作
2. 过滤条件放置位置不当
3. 排序操作效率低下

优化后SQL：

SELECT order_id, user_id, amount, status 
FROM orders_2023 WHERE amount > 1000
UNION ALL
SELECT order_id, user_id, amount, status 
FROM orders_2024 WHERE amount > 1000
ORDER BY order_date DESC;

优化效果：查询时间从15秒降至0.8秒

五、高级优化技巧

1. 执行计划分析

EXPLAIN 
SELECT * FROM table1
UNION ALL
SELECT * FROM table2;

关键观察指标：

• Extra字段：避免”Using temporary”和”Using filesort”
• type字段：确保使用索引
• rows字段：评估扫描行数

2. 索引优化策略

• 为UNION字段建立复合索引
• 确保ORDER BY字段有索引支持
• 思考覆盖索引减少回表

3. 参数调优

-- 调整排序缓冲区大小
SET sort_buffer_size = 64 * 1024 * 1024;

-- 设置临时表大小
SET tmp_table_size = 256 * 1024 * 1024;

六、面试应答指南

系统化回答框架

1. 基础区别：明确UNION和UNION ALL的机制差异
2. 性能分析：阐述去重操作的具体开销
3. 优化策略：列举具体的优化方法和适用场景
4. 实战经验：分享实际案例和性能提升效果
5. 架构思维：提出替代方案和长期优化思路

常见问题应对

问：什么情况下必须使用UNION？
答：当业务逻辑要求结果集必须去重，且无法通过其他方式保证数据唯一性时。但需要评估性能代价，并思考能否在数据源头避免重复。

问：如何评估UNION查询的性能？
答：通过EXPLAIN分析执行计划，重点关注临时表使用、排序操作和索引利用情况。同时结合实际执行时间和大数据量下的扩展性。

七、总结

UNION查询优化是一个需要系统化思维的技术领域。通过本文的分析，我们可以得出以下核心结论：

1. 优先原则：在不需要去重的场景下，始终坚持使用UNION ALL
2. 过滤前置：在子查询中尽早过滤数据，减少UNION操作的数据量
3. 索引优化：确保相关字段有合适的索引支持
4. 架构思维：思考分区表、物化视图等替代方案
5. 持续监控：定期分析慢查询日志，持续优化UNION查询性能

通过系统化的优化策略，可以显著提升UNION查询的性能，为应用程序提供更好的数据库性能保障。