MySQL不支持EXCEPT，需用LEFT JOIN+IS NULL或NOT EXISTS替代；EXCEPT按位置匹配列，要求列数相同、类型兼容，NULL值影响结果，性能依赖子查询优化。
EXCEPT 在 PostgreSQL 和 SQL Server 里能直接用，MySQL 不行
MySQL 8.0.19 之前压根没有 EXCEPT 关键字，写完直接报错 ERROR 1064。不是语法写错了，是数据库根本不认这个操作符。PostgreSQL、SQL Server、Oracle 都支持标准的 EXCEPT（或 MINUS），但行为细节有差异：PostgreSQL 默认去重，SQL Server 也是；而 Oracle 的 MINUS 会自动去重且要求列数、类型严格匹配。
如果必须在 MySQL 里做差集，得换思路——用 LEFT JOIN + IS NULL 模拟，或者用 NOT EXISTS。别硬套 EXCEPT，否则连执行都过不去。
列名、顺序、类型不一致会导致 EXCEPT 失效
EXCEPT 不看列名，只按位置匹配。左边查询的第 1 列和右边查询的第 1 列会被比较，即使名字不同、类型隐式转换失败，也会报错或返回空结果。
- 确保两个查询返回的列数完全相同
- 同位置列的数据类型尽量一致，比如别让
INT对VARCHAR，尤其在 SQL Server 中容易触发隐式转换失败 - 显式用
CAST或CONVERT统一类型，例如把created_at都转成DATE再比 - 列名可以不同，但别依赖它——结果集的列名取自左侧查询
NULL 值会让 EXCEPT 返回不符合直觉的结果
EXCEPT 把整行当一个元组比较，而 SQL 中 NULL = NULL 是未知（UNKNOWN），不是真。所以含 NULL 的行默认不会被当作“相同”而排除——哪怕两行其他字段全一样，只有一列是 NULL，它们就被视为不同。
常见现象：你肉眼觉得“这两条记录应该被差掉”，但结果里还留着。原因往往就是某列值为 NULL。解决办法：
- 提前用
COALESCE(col, 'N/A')或IFNULL(col, -1)把NULL转成确定值 - 确认业务逻辑是否允许这样替换——有些场景
NULL本身就代表“未知”，不能简单等同于占位符 - 测试时手动查出含
NULL的行，单独验证差集逻辑
性能差？可能是没走索引或数据量太大
EXCEPT 底层通常要对两个结果集排序 + 去重 + 合并，如果子查询本身没优化，很容易慢到超时。特别是两边都涉及大表关联、没加 WHERE 过滤时。
提速关键点：
- 先保证两个子查询各自能走索引——检查
EXPLAIN输出里的key和rows - 差集前尽可能缩小数据范围，比如加时间范围、状态过滤：
WHERE status = 'active' AND created_at > '2024-01-01' - 避免在
EXCEPT外层再套复杂计算，它本身已经很重了 - 如果只是临时比对、数据量不大（set 差集反而更快
差集逻辑看着简单，但列对齐、NULL 处理、引擎兼容性这三块最容易卡住人。动手前先 SELECT * FROM (...) AS a LIMIT 5 和 SELECT * FROM (...) AS b LIMIT 5 看一眼结构，省掉一半调试时间。
