INTERSECT、EXCEPT在MySQL 8.0.31+中的执行机制与性能对比

大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！

SQL里有一类操作，看起来很简单，写起来也很顺手——UNION、INTERSECT、EXCEPT。三个词搞定并集、交集、差集，比写一堆JOIN和子查询清爽多了。

但“写得顺手”和“跑得顺心”是两回事。

一条UNION可能让查询从200ms飙到2秒；一个INTERSECT可能比INNER JOIN慢4.7倍；EXCEPT在NULL面前的行为，可能跟你以为的“减法”根本不是一回事。

今天把集合操作的底层执行差异彻底拆开讲一遍。

一、先搞清楚集合操作是什么

集合操作（Set Operations）是SQL标准中用于合并多个SELECT结果集的运算符。主要包括三种：

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自动去重的“双面性”：

这是好事——你不需要额外写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万沉默用户漏进了活跃用户池，最终影响了千万级营销预算的投放。

五、集合操作的选型建议

总结

集合操作写起来简单，但“写得顺手”和“跑得顺心”是两回事。把三条原则记住：

1. 能不用UNION就不用UNION——默认用UNION ALL，除非你明确需要去重

2. INTERSECT能用INNER JOIN替代就用INNER JOIN——性能更好，语义更可控

3. EXCEPT和NOT EXISTS之间，优先NOT EXISTS——规避NULL陷阱，支持索引

集合操作的底层执行差异，本质上是去重、排序、临时表、索引利用之间的权衡。理解了这些，你就能写出“既正确又高效”的集合查询。

小耶在手，SQL 不愁

还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽……我们下次见~