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

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

二、UNION与UNION ALL的核心区别底层机制对比UNION：执行去重操作，需要额外的排序/哈希和重复数据消除步骤UNION ALL：简单的结果集拼接，无去重开销性能影响分析-- 性能差异示例SELECT id, name FROM table1 UNIONSELECT id, name FROM table2; -- 需要去重，性能较低SELECT id, name FROM table1 UNION ALLSELECT id, name FROM table2; -- 直接拼接，性能更高三、UNION查询的六大优化策略1. 优先使用UNION ALL

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

-- 错误示例：不必要的去重SELECT user_id FROM orders_2023UNIONSELECT user_id FROM orders_2024;-- 优化示例：使用UNION ALLSELECT user_id FROM orders_2023UNION ALLSELECT user_id FROM orders_2024;2. 预先数据过滤

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

-- 错误示例：先UNION后过滤SELECT * FROM ( SELECT * FROM table1 UNION ALL SELECT * FROM table2) AS tmp WHERE condition = true;-- 优化示例：先过滤后UNIONSELECT * FROM table1 WHERE condition = trueUNION ALLSELECT * FROM table2 WHERE condition = true;3. 避免子查询排序

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

-- 错误示例：子查询排序(SELECT * FROM table1 ORDER BY col1)UNION ALL(SELECT * FROM table2 ORDER BY col2);-- 优化示例：最终统一排序SELECT * FROM table1UNION ALLSELECT * FROM table2ORDER BY final_column;4. 限制返回字段

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

-- 错误示例：返回过多字段SELECT * FROM table1UNIONSELECT * FROM table2;-- 优化示例：精确选择字段SELECT id, name, status FROM table1UNION ALLSELECT id, name, status FROM table2;5. 使用临时表处理复杂UNION

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

-- 创建临时表存储中间结果CREATE TEMPORARY TABLE temp_results ASSELECT col1, col2 FROM table1 WHERE condition;-- 使用临时表进行UNIONSELECT * FROM temp_resultsUNION ALLSELECT col1, col2 FROM table2 WHERE condition;6. 考虑替代方案

架构级优化：

使用分区表替代频繁的UNION操作通过物化视图预聚合数据采用联合查询优化器提示四、实战优化案例案例背景

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

原始低效SQL：

SELECT order_id, user_id, amount, status FROM orders_2023UNIONSELECT order_id, user_id, amount, status FROM orders_2024WHERE amount > 1000ORDER BY order_date DESC;

问题分析：

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

优化后SQL：

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

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

五、高级优化技巧1. 执行计划分析EXPLAIN SELECT * FROM table1UNION ALLSELECT * 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;六、面试应答指南系统化回答框架基础区别：明确UNION和UNION ALL的机制差异性能分析：阐述去重操作的具体开销优化策略：列举具体的优化方法和适用场景实战经验：分享实际案例和性能提升效果架构思维：提出替代方案和长期优化思路常见问题应对

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

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

七、总结

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

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

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