大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！
SQL里有一类操作，看起来很简单，写起来也很顺手——UNION、INTERSECT、EXCEPT。三个词搞定并集、交集、差集，比写一堆JOIN和子查询清爽多了。
但“写得顺手”和“跑得顺心”是两回事。
一条UNION可能让查询从200ms飙到2秒；一个INTERSECT可能比INNER JOIN慢4.7倍；EXCEPT在NULL面前的行为，可能跟你以为的“减法”根本不是一回事。
今天把集合操作的底层执行差异彻底拆开讲一遍。
一、先搞清楚集合操作是什么
集合操作（Set Operations）是SQL标准中用于合并多个SELECT结果集的运算符。主要包括三种：
| 操作符 | 功能 | 是否去重 | MySQL版本要求 |
UNION |
并集 | ✅ 去重 | 所有版本 |
UNION ALL |
并集 | ❌ 不去重 | 所有版本 |
INTERSECT |
交集 | ✅ 去重 | 8.0.31+ |
EXCEPT |
差集 | ✅ 去重 | 8.0.31+ |
UNION在MySQL 5.7时代就有了，INTERSECT和EXCEPT是MySQL 8.0.31才加入的新成员。很多人写了多年SQL，可能只用过UNION ALL，对另外两个既熟悉又陌生。
二、UNION vs UNION ALL：一个“ALL”字，差了一个数量级
UNION和UNION ALL的语法差异只有一个词，但执行计划的差异是结构性的。
执行计划差异：
UNION ALL的执行树是干净的两支并行流——Append → 扫描表A → 扫描表B，数据从子查询直接推给上层，纯流式输出，无需等待。
UNION的执行树多了一个关键节点——Distinct → Append → 扫描表A → 扫描表B。
这个Distinct节点是所有性能损耗的源头。它不是简单的“内存里扫一遍去重”，而是触发了一整套资源调度策略：数据库必须决定用排序去重还是哈希去重，如果数据量超过sort_buffer_size（默认256KB），就要写临时文件到磁盘。
实测数据：
当两张子查询结果集各含12万行、重复率仅0.3%时，UNION比UNION ALL多消耗2.1GB临时空间，查询耗时从186ms跳到2140ms。重复率越低，UNION的额外开销越显得“冤”——它为了去重付出了巨大的代价，但实际重复的行几乎没有。
什么时候该用UNION？
- 两个结果集确实可能重复，且必须去重
- 数据量小（千行级别）
- 业务逻辑明确要求“合并并去重”
什么时候该用UNION ALL？
- 你确定两个结果集不会重复（比如查询不同表的不同主键范围）
- 你不需要去重
- 绝大多数场景——优先用
UNION ALL，除非你明确需要去重
记住：UNION本质是UNION ALL + DISTINCT。如果你不需要DISTINCT，就别为它买单。
三、INTERSECT：交集，但不只是“两个表的交集”
INTERSECT返回两个查询结果中都存在的行。很多人以为它跟INNER JOIN差不多，但两者有本质区别：
| 对比维度 | INTERSECT | INNER JOIN |
| 返回结果 | 自动去重 | 可能返回重复行 |
| NULL处理 | 将NULL视为相等 | 不返回NULL |
| 列要求 | 列数、类型、顺序严格一致 | 通过ON条件关联 |
| 语义 | 集合交集 | 关系连接 |
INTERSECT自动去重的“双面性”：
这是好事——你不需要额外写DISTINCT。但这也可能带来意外：如果你期望的是“每个匹配行都返回”，INTERSECT可能会悄悄“吞掉”重复行。
INTERSECT与INNER JOIN的性能差异：
在MySQL 8.0中，INTERSECT的执行计划通常比INNER JOIN多一层去重操作。当两个结果集都很大且重复率低时，这个去重开销会显著拉高耗时。有实测显示，INTERSECT比INNER JOIN慢4.7倍。
四、EXCEPT：差集，但NULL是个坑
EXCEPT返回第一个查询结果中存在、但第二个查询结果中不存在的行。
EXCEPT vs NOT EXISTS vs NOT IN：
NULL的“隐形陷阱”：
EXCEPT将NULL视为相等，而NOT IN中如果子查询结果包含NULL，整个查询返回空集。某电商大促期间，一个用EXCEPT做用户分群的报表，因NULL值参与比较被判定为“不相等”，硬生生把23万沉默用户漏进了活跃用户池，最终影响了千万级营销预算的投放。
五、集合操作的选型建议
总结
集合操作写起来简单，但“写得顺手”和“跑得顺心”是两回事。把三条原则记住：
- 能不用UNION就不用UNION——默认用UNION ALL，除非你明确需要去重
- INTERSECT能用INNER JOIN替代就用INNER JOIN——性能更好，语义更可控
- EXCEPT和NOT EXISTS之间，优先NOT EXISTS——规避NULL陷阱，支持索引
集合操作的底层执行差异，本质上是去重、排序、临时表、索引利用之间的权衡。理解了这些，你就能写出“既正确又高效”的集合查询。
小耶在手，SQL 不愁
还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽……我们下次见~
