UNION和EXCEPT是SQL中基于集合操作的关键工具，分别用于合并结果集与找出行间差异，UNION默认去重而UNION ALL保留重复，EXCEPT实现集合差，常可被LEFT JOIN或NOT EXISTS替代以提升性能，使用时需确保列数和数据类型兼容，并优先在子查询中过滤数据、避免子查询内使用ORDER BY，合理利用索引和选择适当去重策略可显著优化查询效率。
SQL中的“并”与“差”操作，也就是我们常说的
UNION和
EXCEPT（或者在某些数据库中是
MINUS），是处理数据集关系的强大工具。它们允许我们将多个查询的结果集合并，或者找出两个结果集之间的差异。实现上，它们直接作用于
SELECT语句的输出，将不同来源的数据视为集合进行操作，而优化则关乎如何高效地处理这些集合，特别是涉及到去重和临时表的使用。
解决方案
在我看来，理解SQL中的“并”（
UNION）和“差”（
EXCEPT）操作，首先要从它们作为集合操作的本质出发。它们不是像
JOIN那样在列的维度上扩展数据，而是在行的维度上合并或比较。
UNION操作用于合并两个或多个
SELECT语句的结果集。它有一个非常重要的特性：默认会去除重复的行。如果你不希望去除重复行，而是想保留所有行，那么应该使用
UNION ALL。这两种方式在性能上会有显著差异，因为去重通常需要额外的排序或哈希处理。
举个例子： 假设我们有两张表，
employees_2022和
employees_2023，它们都记录了员工ID和姓名。
-- 找出2022和2023年所有不重复的员工 SELECT employee_id, employee_name FROM employees_2022 UNION SELECT employee_id, employee_name FROM employees_2023; -- 找出2022和2023年所有员工，包括重复的（如果一个员工两年都在职） SELECT employee_id, employee_name FROM employees_2022 UNION ALL SELECT employee_id, employee_name FROM employees_2023;
而
EXCEPT（在SQL Server、PostgreSQL等中使用）或
MINUS（在Oracle中使用）则用于从第一个
SELECT语句的结果集中减去第二个
SELECT语句中存在的行。换句话说，它返回只存在于第一个结果集，而不存在于第二个结果集中的那些行。
-- 找出只在2022年，不在2023年的员工 SELECT employee_id, employee_name FROM employees_2022 EXCEPT SELECT employee_id, employee_name FROM employees_2023;
使用这些操作时，一个基本要求是所有参与操作的
SELECT语句必须拥有相同数量的列，并且对应列的数据类型必须兼容。如果数据类型不完全一致，数据库通常会尝试进行隐式转换，但这可能会带来性能开销，甚至导致意想不到的结果。
SQL并差操作的底层逻辑与性能考量：为何需要理解它们？
说实话，很多人在初学SQL时，可能会觉得
UNION和
EXCEPT只是简单的语法糖。但深入了解它们的底层逻辑，你会发现这直接关系到查询的性能瓶颈。数据库在执行这些集合操作时，通常会经历几个关键步骤。
对于
UNION，数据库引擎会首先执行每个子查询，将它们的结果集收集起来。如果使用的是
UNION（非
ALL），接下来的关键一步就是去重。这个去重过程通常需要将所有结果加载到一个临时空间（可能是内存，也可能是磁盘），然后进行排序或哈希操作来识别并移除重复行。这个排序或哈希，在数据量庞大时，会消耗大量的CPU和I/O资源。我曾遇到过一个案例，一个看似简单的
UNION查询，因为涉及几百万行的数据，导致CPU飙升，最后发现是
DISTINCT操作在拖后腿，改用
UNION ALL并手动处理去重（如果业务允许）才解决。
而
UNION ALL则简单得多，它只是将所有子查询的结果直接拼接起来，不做去重处理，因此通常比
UNION快得多。
EXCEPT的逻辑则更像是执行一个“左反连接”（Left Anti Join）。数据库会获取第一个结果集的所有行，然后与第二个结果集进行比较，找出那些在第二个结果集中找不到匹配的行。这个比较过程同样可能涉及临时表的创建和数据扫描。其性能同样受到数据量、索引可用性以及比较算法的影响。
理解这些底层机制的重要性在于，它能指导我们做出更明智的查询设计决策。例如，当你看到一个查询使用了
UNION而性能不佳时，你就会自然而然地思考：是不是可以改成
UNION ALL？或者，如果业务确实需要去重，能否将去重操作推迟到应用层，或者通过其他SQL结构（如
GROUP BY）在更小的结果集上进行？这些考量，远比仅仅知道语法要来得实用。
优化SQL并差查询的实用策略与常见陷阱
优化SQL的并差查询，核心思想无非是减少处理的数据量，并利用数据库的优势。这里有一些我常用的策略和踩过的坑：
首先，优先使用UNION ALL
。这是最直接、最有效的优化手段。如果你确定子查询结果没有重复，或者业务逻辑允许重复（比如只是为了统计总数），就坚决使用
UNION ALL。如果确实需要去重，可以考虑在
UNION ALL的结果上再加一个
DISTINCT或
GROUP BY，但更优的做法是在子查询中就尽量减少重复，或者在业务层面上处理去重逻辑。
其次，在子查询中尽可能过滤数据。
WHERE子句是你的朋友。在
UNION或
EXCEPT操作之前，确保每个子查询都尽可能地缩小了结果集。传递给
UNION/
EXCEPT的数据量越小，最终的集合操作就越快。比如，你可能不需要合并所有历史数据，而只需要最近一年的。
-- 优化前：合并所有历史数据再筛选 SELECT id, name FROM sales_2022 UNION ALL SELECT id, name FROM sales_2023 WHERE sale_date >= '2023-01-01'; -- 错误用法，WHERE作用于最终结果，效率低 -- 优化后：在子查询中就筛选 SELECT id, name FROM sales_2022 WHERE sale_date >= '2023-01-01' UNION ALL SELECT id, name FROM sales_2023 WHERE sale_date >= '2023-01-01';
再者，考虑替代方案。并不是所有情况都必须使用
UNION或
EXCEPT。例如，
EXCEPT的很多场景可以用
LEFT JOIN加
WHERE IS NULL或
NOT EXISTS来替代。
-- SELECT * FROM A EXCEPT SELECT * FROM B; 的替代方案
SELECT A.*
FROM A
LEFT JOIN B ON A.col1 = B.col1 AND A.col2 = B.col2 -- 确保所有比较列都包含
WHERE B.col1 IS NULL;
-- 或者使用 NOT EXISTS
SELECT A.*
FROM A
WHERE NOT EXISTS (
SELECT 1 FROM B WHERE B.col1 = A.col1 AND B.col2 = A.col2
);这些替代方案在某些特定场景下，尤其是当索引能够被有效利用时，性能可能会优于直接的
EXCEPT。这需要具体分析执行计划。
最后，索引优化。虽然
UNION/
EXCEPT操作本身可能不直接使用索引（因为它们作用于子查询的结果集），但确保子查询中涉及的列有合适的索引，能极大地加速子查询的执行，从而减少需要集合操作的数据量。
常见的陷阱包括：在每个子查询中都加上
ORDER BY。这通常是多余的，因为
UNION或
EXCEPT操作之后，如果需要排序，通常会在最终结果集上进行一次排序。在子查询中排序不仅浪费资源，而且结果集的顺序在集合操作后也无法保证。还有就是数据类型的不匹配，虽然数据库会尝试隐式转换，但这会带来额外的开销，并且可能导致数据精度丢失或意外的结果。
高级应用场景：如何利用并差操作解决复杂数据分析问题？
并差操作的强大之处在于它们对“集合”概念的直接映射，这在许多复杂的数据分析场景中显得尤为有用。
一个非常典型的应用是数据清洗与比对。假设你需要找出两个系统（或表）之间的数据差异，比如新旧系统的数据迁移后，需要验证数据一致性。
- 找出只在新系统有，旧系统没有的数据：
SELECT * FROM NewSystemData EXCEPT SELECT * FROM OldSystemData;
- 找出只在旧系统有，新系统没有的数据（即迁移过程中丢失的）：
SELECT * FROM OldSystemData EXCEPT SELECT * FROM NewSystemData;
通过这两个查询，你可以快速定位到不一致的数据点，进行后续的处理。
另一个常见场景是跨业务线或跨部门的报表整合。如果不同业务部门的销售数据结构类似，但存储在各自独立的表中，为了生成一个汇总报表，
UNION ALL就非常合适。
SELECT sales_date, product_id, amount, 'DeptA' as source_dept FROM DeptA_Sales UNION ALL SELECT sales_date, product_id, amount, 'DeptB' as source_dept FROM DeptB_Sales UNION ALL SELECT sales_date, product_id, amount, 'DeptC' as source_dept FROM DeptC_Sales;
这样，你可以轻松地将来自不同源的数据合并到一起，进行进一步的聚合分析。
此外，用户行为分析中的路径缺失或特定群体识别也能用到。例如，你想找出所有注册了但从未登录过的用户：
SELECT user_id FROM RegisteredUsers EXCEPT SELECT user_id FROM LoggedInUsers;这比使用复杂的
LEFT JOIN或子查询来判断“不存在”要直观得多。
甚至在复杂权限管理中，当一个用户可能属于多个用户组，每个组都有不同的权限集合时，你可以用
UNION来合并这些权限，找出用户最终拥有的所有权限。
SELECT permission_code FROM UserGroupA_Permissions UNION SELECT permission_code FROM UserGroupB_Permissions;
这些例子都表明，
UNION和
EXCEPT不仅仅是SQL语法的一部分，它们提供了一种强大的、集合论式的思维方式来处理数据。当你面对需要合并、比较或找出数据差异的需求时，首先想到它们，往往能让你的解决方案更加清晰和高效。当然，前提是你得对数据的“集合”特性有清晰的认识，并能预见到其潜在的性能影响。
