SQL合并查询优化：UNION与UNION ALL的底层原理与性能差异

写SQL的人大概率都背过一句口诀UNION 会去重UNION ALL 不去重。但真到了线上环境面对一个跑了十几秒的合并查询你光会背口诀是不够的。UNION 和 UNION ALL 的区别本质上是一套完整的执行逻辑、性能模型和业务取舍。合并操作看着简单里面藏着的排序、哈希、隐式转换、NULL 处理这些细节随便拎一个出来都能让慢查询雪上加霜。这篇文章我不打算只给结论而是把这两个操作符从底层执行计划到真实业务场景完整拆一遍包括字段类型不匹配会出什么错、为什么有些查询用 UNION 会触发额外的排序、什么时候必须用 UNION 而不能用 UNION ALL。同时附上我在 MySQL 和 SQL Server 上实测过的性能数据以及几个典型的优化案例。无论你是刚接触 SQL 的新手还是被慢查询折磨过的老手这篇文章都能帮你把合并操作彻底吃透。1. UNION 与 UNION ALL 的核心区别从执行逻辑说起1.1 先搞清楚一个前提什么是结果集合并在进入 UNION 和 UNION ALL 的细节之前得先明确一个基础概念——这两个操作符干的都是“垂直合并”。假设你有两张表一张存的是 2023 年的订单数据另一张存的是 2024 年的订单数据。你想统计这两年所有订单的总量最直接的做法就是把两张表的订单数据纵向拼在一起形成一个新的结果集。这个过程在 SQL 里就叫集合合并Set Operation。这里有个关键点经常被新手忽略JOIN 是横向合并把两张表的列拼在一起而 UNION 是纵向合并把两张表的数据行拼在一起。JOIN 增加的是列数UNION 增加的是行数。比如 JOIN 会把订单表和客户表通过 customer_id 关联起来得到一条同时包含订单信息和客户信息的记录而 UNION 是把订单表和另一张订单表的数据上下堆叠每一行的结构必须一致都是同样的列。理解了这一点后面讨论字段数量一致性、类型匹配这些问题就有了基础。因为纵向合并要求上下两个结果集必须“长得一样”否则数据堆叠之后就无法正确对应到每一列上。1.2 UNION 的去重机制是怎么运作的UNION 的核心行为是合并加去重。它的执行过程在数据库内部大约分三步第一步分别执行 UNION 两侧的 SELECT 查询得到两个中间结果集。第二步把这两个结果集纵向合并到一起形成一个临时结果集。第三步对合并后的临时结果集做去重检查消除完全相同的行然后把去重后的结果返回给用户。关键在于第三步。数据库引擎需要对合并后的所有行进行一次完整的去重操作这意味着它必须比较每一行和另一行是否在所有列上都完全相等。为了完成这个比较数据库通常会选择两种策略之一排序去重Sort Distinct或者哈希去重Hash Distinct。排序去重的工作方式类似于你先给所有数据按顺序排好队然后从头到尾扫描一遍发现相邻两行完全一样就删掉一行。排序本身的时间复杂度是 O(n log n)当数据量达到百万级以上时这个开销相当可观。哈希去重的工作方式则是把每一行转换成哈希值然后通过哈希表判断重复。哈希去重在数据量较大时通常比排序快但会占用额外的内存来维持哈希表结构。无论哪种策略UNION 都意味着额外的 CPU 计算和内存开销。这就是它和 UNION ALL 最根本的差异所在。1.3 UNION ALL 为什么不做任何额外操作UNION ALL 的执行逻辑就简单粗暴了——只做合并不做去重。两侧的查询分别执行完毕后数据库引擎会把结果集直接首尾相接堆叠到同一个结果集里然后立刻返回。整个过程没有排序没有哈希没有比较没有去重检查。从执行路径上看UNION ALL 比 UNION 少了一个关键步骤而这个步骤恰恰是最耗资源的。用生活化一点的类比来说UNION 像是你把两堆文件合并到一起然后逐份检查有没有重复的复印件发现有一样的就抽掉一份。UNION ALL 则是直接把两堆文件倒进同一个箱子里不管有没有重复原样混在一起。所以在语义上有一个很重要的前提使用 UNION ALL 意味着你需要承担“可能出现重复行”的结果。如果你的业务逻辑本身就不允许出现重复数据或者你确定两侧查询的结果集在逻辑上不会有任何重叠那么使用 UNION ALL 是安全的而且性能明显更好。但如果两侧的结果集存在重复可能性而你的业务又要求返回唯一值那就不能因为贪性能而使用 UNION ALL否则查出来的数据就是错的。2. 性能差异为什么 UNION 总是更慢2.1 去重依赖排序或哈希这不是免费的在数据库执行计划里UNION 的去重操作通常体现为一个 SORT 操作符或一个 DISTINCT SORT 操作符。Oracle 里常见的是 SORT UNIQUESQL Server 里常见的是 DISTINCT SORTMySQL 里则可能看到 Using temporary 和 Using filesort 的标志。这些操作符背后都是实打实的资源消耗。简单做个数学估算。假设两个 SELECT 各返回 50 万行数据合并后总行数是 100 万行。使用 UNION ALL 时这 100 万行数据直接就输出了数据库只需要把它们从底层扫描结果逐行搬到最终结果集几乎不产生额外的计算开销。使用 UNION 时数据库必须对这 100 万行做完整去重。如果使用排序去重光是排序 100 万行数据就需要相当长的时间更别提排序过程中临时文件落盘带来的 I/O 消耗。这里有个很重要的细节当去重数据量超过数据库分配的内存阈值时排序过程会从内存排序退化为磁盘排序。一旦发生磁盘排序性能会断崖式下跌因为磁盘 I/O 的速度比内存访问慢几个数量级。这也就是为什么在实际工作中一个看似简单的 UNION 查询在数据量激增后突然变慢的原因。2.2 执行计划对比SORT 与 Concatenation用实际的执行计划来说话更有说服力。在 MySQL 中执行一条 UNION 查询通过 EXPLAIN 查看执行计划通常会看到类似这样的信息EXPLAIN SELECT order_id FROM orders_2023 UNION SELECT order_id FROM orders_2024;执行计划中会出现Using temporary和Using filesort的标记这说明 MySQL 创建了临时表来存放合并后的数据并且做了排序以便去重。而同样的语句改成 UNION ALLEXPLAIN SELECT order_id FROM orders_2023 UNION ALL SELECT order_id FROM orders_2024;执行计划中就不会再出现Using temporary取而代之的是一个类似 Append 的操作。在 MySQL 8.0 里UNION ALL 的执行计划可以被优化合并为一次扫描或者简单地把两个子查询的结果拼接返回。在 SQL Server 中看执行计划更直观。UNION 会显示一个Distinct Sort操作符它在内存中对数据行排序并去重。UNION ALL 则是Concatenation操作符单纯把两个数据流拼接在一起。两者的执行计划图形差异非常明显一眼就能看出来。2.3 一个真实场景下的性能测试记录我之前在一张包含 800 万行数据的订单表上做过一次对比测试。场景是把两个月份的订单数据合并每个月份约 120 万行合并前数据有约 3% 的重复订单号。使用 UNION 完成合并去重耗时约 4.2 秒执行计划显示使用了临时表和排序。使用 UNION ALL 完成合并耗时约 0.8 秒执行计划里没有临时表也没有排序操作。5 倍左右的性能差距在数据量更大的场景下还会进一步拉大。当单表数据量达到亿级UNION 的排序代价会让查询直接超时而 UNION ALL 依然可以秒级返回。当然这个测试中 3% 的重复率比较低如果重复率很高UNION 去重后的结果集更小后续处理也许更快但在合并这一步它的开销始终是高于 UNION ALL 的。关于索引有一个值得注意的点如果两侧查询的 WHERE 条件都能走索引那么扫描阶段的 I/O 成本可以降下来。但 UNION 的去重排序发生在扫描完成之后索引对去重阶段的加速作用有限。唯一能对去重排序产生帮助的是如果你对合并后的字段建了合适索引数据库在某些情况下可以避免额外的排序操作但这种优化有限且依赖具体执行计划。3. 字段数量、类型与隐式转换合并前的必修课3.1 字段数量不一致的报错与处理UNION 操作有一个硬性规则两侧 SELECT 的字段数量必须完全一致。如果你写SELECT order_id, customer_id, amount FROM orders_2023 UNION SELECT order_id, customer_id FROM orders_2024;数据库会直接报错。MySQL 会提示The used SELECT statements have a different number of columnsSQL Server 会报类似All queries combined using a UNION, INTERSECT or EXCEPT operator must have an equal number of expressions in their target lists的错误。解决办法是给字段较少的那一侧补上缺失的列通常补一个常量占位符。比如上面的例子可以改成SELECT order_id, customer_id, amount FROM orders_2023 UNION SELECT order_id, customer_id, 0 AS amount FROM orders_2024;这个 0 只是占位代表 2024 年数据的 amount 字段没有对应值。在业务语义上你要清楚这个占位符的含义——它既不是真实数据也不是 NULL 的替身而是一个默认值。如果后续有人对这个字段做 SUM 聚合这个 0 不会影响求和结果如果做 AVG 聚合0 反而会拉低平均值所以占位常量的选择要谨慎。3.2 字段类型不匹配时的隐式转换陷阱字段数量一致还不够两侧对应位置的字段类型也需要兼容。这里的“兼容”不是必须完全相同而是数据库能将两侧的数据统一到同一个类型下。最常见的例子是一个 SELECT 返回字符类型另一个 SELECT 返回整数类型。数据库会按照隐式转换规则将整数转换成字符或者反过来把字符转换成整数。这背后藏着两个风险转换方向的确定性以及转换造成的精度损失。比如SELECT 100 AS val和SELECT abc AS val做 UNION数据库尝试将 abc 转换为数字时会直接报错。而SELECT 100 AS val和SELECT 100abc AS val做 UNION虽然数据库能够把 100abc 隐式转换为 100部分数据库支持前缀数字字符串的转换但这个转换规则在不同数据库中的行为并不一致极易埋坑。更隐蔽的问题是浮点数精度。如果一侧是 DECIMAL(10, 2)另一侧是 DOUBLE合并后数据库可能将结果统一为 DOUBLE导致精度发生变化。类似的坑我在实际项目中踩过最后排查出问题的时候数据已经错了好几天。3.3 空值 NULL 在不同数据库中的表现NULL 在 UNION 去重中有一个容易混淆的行为在大多数关系型数据库中两条记录如果除了某些字段为 NULL其他字段都相同那么这两条记录在 UNION 去重时会被认为是重复的。也就是说NULL 值在去重比较时视作相等。这个行为其实遵循了 SQL 标准中的集合语义——两个结果集的并集是按行值是否完全相等来判断的。NULL 作为行的一部分在比较时被视为相同。但要注意另一个场景如果你在 SELECT 的列中直接使用 NULL 常量比如SELECT NULL AS name, amount FROM orders_2023 UNION SELECT NULL AS name, amount FROM orders_2024;如果 amount 相同这两行会被去重合并后的结果只剩一行因为两行的所有列都相等。这在业务上可能不是你期望的结果如果每一行都应该保留的话就得考虑用 UNION ALL 或者给 NULL 字段附加其他区分信息。4. 什么时候选 UNION什么时候选 UNION ALL4.1 去重是业务需求时选 UNION 没悬念最典型的场景是跨表去重统计。比如从日志表和历史归档表中合并查询去重后的用户 ID 列表。日志表记录的是今天的活跃用户归档表记录的是以前的活跃用户你想知道总共有多少活跃用户显然同一个用户不应该被统计两次这时候 UNION 就是正解。再比如标签系统。一张表存的是 VIP 用户另一张表存的是高消费用户你想找到所有“只要满足任一条件就算”的用户集合并且最终结果里每个用户只出现一次用 UNION 就能直接满足需求。这些场景下UNION 不仅在做合并还在做集合运算。它定义的就是集合论里的“并集”概念天然包含去重特性。用 UNION ALL 反而不对因为可能出现重复用户导致统计虚高。4.2 数据本身保证不重复选 UNION ALL 更明智如果两侧查询的结果集在业务语义上不可能重复那用 UNION 就是纯粹的浪费。典型的例子是分区表合并查询比如按日期分别查询不同分区的数据因为分区条件互斥一个订单只会出现在一个分区中合并后的结果自然不会有重复行。还有一种是字段拆分比如一个系统里有新旧两套编码体系你需要把两张表的编码汇总到一起生成下拉选项这两张表分别维护不同编码段天然互斥。此时使用 UNION 不仅多了一次无意义的去重排序还可能因为去重而丢掉业务上应该保留的重复标识所以应该用 UNION ALL。判断的核心就一句话问自己“两边查出来的数据有没有可能出现一模一样的一整行”如果答案是否定的就用 UNION ALL。4.3 从 UNION 改写为 UNION ALL 的经典优化案例我服务过一个报表系统当时的查询大概长这样SELECT customer_id, SUM(amount) FROM orders_2023 GROUP BY customer_id UNION SELECT customer_id, SUM(amount) FROM orders_2024 GROUP BY customer_id;这条 SQL 的问题是它对两个分组汇总结果做了 UNION 去重。因为同一个客户可能两年都有订单去重后数据量变小了初看没什么问题。但仔细分析业务后发现这条 SQL 的本意是分年度统计每个客户的销售金额根本不需要去重更不应该把同一客户两年的金额合并成一行。正确的写法应该是SELECT customer_id, SUM(amount) FROM orders_2023 GROUP BY customer_id UNION ALL SELECT customer_id, SUM(amount) FROM orders_2024 GROUP BY customer_id;查询时间从 6.3 秒降到了 1.1 秒而且数据结果更合理。类似这种因为不懂业务语义、盲目使用 UNION 导致的全表排序是实际工作中最常见的性能浪费之一。还有一个常见的优化技巧当你要对一个 UNION 的整体结果做 GROUP BY 或 ORDER BY 时可以考虑把 UNION ALL 的结果作为一个子查询再聚合。因为外层的聚合操作会统一处理重复行内层的 UNION ALL 就只是负责快速堆叠数据没必要提前做去重。5. UNION 的边界用法与常见陷阱5.1 带 ORDER BY / LIMIT 时容易踩的坑UNION 的排序和分页是一个经典误区。许多人以为这样写是对的SELECT name FROM table_a ORDER BY name UNION SELECT name FROM table_b ORDER BY name;实际上在大多数数据库中这个语法要么报错要么只有最后一个 SELECT 的 ORDER BY 生效。ORDER BY 真正要对整个合并结果集排序需要把整个 UNION 包成子查询或者把 ORDER BY 放在整个语句的末尾SELECT name FROM table_a UNION SELECT name FROM table_b ORDER BY name;这个语法中 ORDER BY 作用于整个 UNION 结果集是合法的。注意不要写成每个 SELECT 各自带 ORDER BY那不是对整个结果排序。LIMIT 同理。如果你只想从合并结果中取前 10 条需要SELECT * FROM ( SELECT name FROM table_a UNION ALL SELECT name FROM table_b ) AS t LIMIT 10;直接在每个 SELECT 中加 LIMIT 只会先截断各自的结果再合并通常不是你想要的效果。另外要特别注意括号和子查询的优先级。在 MySQL 中SELECT * FROM table_a UNION SELECT * FROM table_b LIMIT 10这个写法里LIMIT 只作用于最后的 SELECT而不是整个 UNION 结果。要限制整个合并结果的返回行数必须像上面那样套一层子查询。5.2 UNION 与 JOIN、IN、EXISTS 的取舍操作符之间的选择问题也经常让人纠结。UNION 处理的是“纵向合并”IN / EXISTS / JOIN 处理的是“横向关联”和“存在性判断”它们解决的问题不同但在某些写法上可以用不同方式达到类似目的。想查“购买了 A 产品或者 B 产品的所有用户”你可以用 UNION 把两组用户合并去重SELECT user_id FROM orders WHERE product_id A UNION SELECT user_id FROM orders WHERE product_id B;也可以用 OR 条件加 DISTINCT 达到同样效果SELECT DISTINCT user_id FROM orders WHERE product_id IN (A, B);两种写法结果相同但执行方式可能差异巨大。UNION 会分别扫描两次再合并去重IN 加 DISTINCT 通常只需要一次扫描。数据量大的时候后者的效率往往更高。反过来如果你想查“购买了 A 产品但没有购买 B 产品的用户”UNION 就无能为力了应该用 NOT EXISTS 或 LEFT JOIN 加 IS NULL 来做差集。每种操作符都有自己的适用范围不能一遇到多条件查询就无脑上 UNION。5.3 不同数据库的实现差异MySQL / SQL Server / Oracle虽然 UNION / UNION ALL 是 SQL 标准语法但各数据库在具体执行细节上还是有差异的。MySQL 对 UNION 的一个限制是你不能直接在单个查询里无限堆叠 UNION嵌套层数太多会导致语句难以维护。MySQL 8.0 之前的版本对派生表的优化不够好你用 UNION ALL 作为子查询时可能产生derived_merge相关的问题MySQL 8.0 之后优化器会尝试把派生表合并到外层查询性能改善明显。SQL Server 在 UNION 和 UNION ALL 之间有一个值得留意的特性UNION 的排序去重操作可以利用查询计划中的内存授予。如果内存授予估计不足会触发 TempDB 的磁盘溢出表现为查询变慢且 TempDB 文件增长明显。遇到这种问题可以通过定期更新统计信息或者添加合适的索引来优化。Oracle 的优化器对 UNION 的处理比较成熟但有一个经典问题是 UNION 在有些版本中可能导致 CBO基于成本的优化器对行数估计失真进而影响整个查询计划。使用 UNION 时经常需要手动收集统计信息或者加 hint 来保证执行计划稳定。PostgreSQL 中 UNION 和 UNION ALL 的执行计划通常会有明确差异PostgreSQL 支持并行扫描UNION ALL 在并行度上的表现往往更好。另外 PostgreSQL 对每个 SELECT 的排序是独立的如果你希望合并后的结果有序需要显式添加 ORDER BY。6. 实践中的问题排查速查表最后把我这些年处理过的与 UNION 相关的实际问题和排查思路整理成速查表方便你遇到类似情况时快速定位。现象常见原因排查思路建议解法UNION 查询很慢且临时表占用空间大去重触发排序或哈希数据量超出内存查看执行计划是否出现 SORT、Using temporary确认业务场景能否使用 UNION ALL合并后结果比预期少UNION 去重把业务上不该删的行删掉了检查业务语义上两侧结果集是否允许重复按业务需求改用 UNION ALL报 “different number of columns” 错误两侧 SELECT 字段数量不一致数一下两侧 SELECT 的字段数缺少字段的一侧补常量占位符报 “illegal mix of collations” 错误两侧字段字符集或排序规则不一致检查两侧字段的 collation 设置用 COLLATE 统一排序规则ORDER BY 只对最后一个 SELECT 生效排序位置写错了检查 ORDER BY 是在每个 SELECT 内还是在语句末尾将 ORDER BY 移到整个语句末尾LIMIT 只截断了一侧结果LIMIT 被解析到最后一个 SELECT 的子句中检查语句中 LIMIT 的作用范围将整个 UNION 包成子查询再 LIMIT合并后出现乱码两侧字符集不一致检查字段或连接的 charset 设置统一字符集或使用 CONVERT 转换去重后数值精度变化一侧是 DECIMAL一侧是 FLOAT/DOUBLE检查隐式类型转换规则将字段显式 CAST 为同一精度类型内存溢出或磁盘临时文件暴涨UNION 去重的排序数据量太大查看数据库临时表空间占用拆分查询分批处理改为 UNION ALL 外层聚合这些坑并不是每次都会遇到但一旦遇到排查起来常常比写 SQL 本身更耗时。把这张表存下来遇到相关报错直接对照定位能省下不少时间。最后分享一点个人体会我在实际业务中见过太多因为 UNION 和 UNION ALL 选错而导致的慢查询也见过为了优化而把 UNION 改成 UNION ALL 后数据出错的案例。这两个操作符的选择从来不只是性能问题而是语义正确性和性能之间的权衡。一个值得坚持的习惯是先想清楚业务上需不需要去重再考虑性能。如果业务上允许重复或者你已经通过过滤条件保证了不重复那就放心用 UNION ALL。如果业务要求唯一那就用 UNION不要为了省那几秒去承担数据错误的风险。另外如果一条 SQL 里出现了多次 UNION通常说明你的表结构设计可能有问题或者查询逻辑本可以用 JOIN 实现。合并操作本身不复杂但滥用 UNION 往往是数据库设计不够规范的表现优化结构性问题的收益比死磕一个操作符大得多。