mysql不支持except，官方明确不计划支持；差集应优先用not exists，因其规避null陷阱、支持索引下推；not in易因null失效，left join...is null则依赖右表字段非空约束。
MySQL 不支持 EXCEPT，硬写会报错 ERROR 1064；想做差集，必须用子查询逻辑替代，其中 NOT EXISTS 是最稳的选择。
为什么不能直接用 EXCEPT？
MySQL 直到 8.0.31 都没实现 EXCEPT（也不是“未来可能加”，是官方明确不计划支持）。你如果从 PostgreSQL 或 SQL Server 迁移 SQL，看到 SELECT a FROM t1 EXCEPT SELECT a FROM t2，在 MySQL 里执行直接失败。
常见错误现象：ERROR 1064 (42000): You have an error in your SQL syntax，定位到 EXCEPT 关键字上。
- 别指望用版本升级解决——它不是被“遗漏”的功能，而是设计上被跳过
- 某些 ORM 或 BI 工具自动生成
EXCEPT，需手动拦截并重写 - MySQL 支持
UNION和UNION ALL，但集合运算仅此而已
NOT IN 看似简单，但含 NULL 就崩
NOT IN 是新手最常用写法：SELECT id FROM table_a WHERE id NOT IN (SELECT id FROM table_b)。但它在真实业务中极易出错，核心问题是 SQL 的三值逻辑：只要 table_b.id 里任意一行是 NULL，整个条件就变成 UNKNOWN，结果集为空。
实操建议：
- 先查
SELECT COUNT(*) FROM table_b WHERE id IS NULL，确认右表有没有空值 - 如果有，
NOT IN必须改写为NOT IN (SELECT id FROM table_b WHERE id IS NOT NULL)，否则结果不可信 - 即使加了
WHERE id IS NOT NULL，性能也差——子查询无法有效利用索引，尤其当table_b很大时
NOT EXISTS 是 MySQL 差集的默认推荐方案
NOT EXISTS 明确表达“对 table_a 每行，检查 table_b 是否存在匹配”，不依赖空值语义，且能走索引。
标准写法：
SELECT a.* FROM table_a a
WHERE NOT EXISTS (
SELECT 1 FROM table_b b
WHERE b.id = a.id
AND b.status = 'active' -- 可加过滤，不影响语义
);
关键点：
- 子查询里用
SELECT 1，不是SELECT *，避免无谓字段传输 -
WHERE条件写在子查询内，而不是外层，才能让优化器把b.status = 'active'下推到table_b扫描前 - 确保
table_b(id)有索引——NOT EXISTS的性能瓶颈几乎总在这里 - 如果要对比多列（比如
(user_id, order_date)），WHERE条件必须全部写出，且注意NULL值仍需显式处理（如用COALESCE）
LEFT JOIN ... IS NULL 可用，但容易踩字段非空陷阱
这种写法直观：SELECT a.* FROM table_a a LEFT JOIN table_b b ON a.id = b.id WHERE b.id IS NULL。但它隐含一个强假设：右表关联字段（这里是 b.id）不允许为 NULL。
一旦 table_b.id 允许 NULL，b.id IS NULL 就分不清是“没匹配上”还是“匹配上了但值就是 NULL”，结果污染。
安全用法：
- 只在明确知道
table_b.id是NOT NULL字段时才用 - 否则必须补条件：
WHERE b.id IS NULL OR b.id IS NOT NULL AND b.id != a.id—— 这已经失去简洁性，不如直接切回NOT EXISTS - JOIN 后若需取
table_b其他字段，务必加IS NULL判断，否则可能意外带出匹配行
真正复杂的差集场景（比如多字段、含 NULL、需保留重复行）往往需要组合 ROW_NUMBER() + NOT EXISTS，但那已超出子查询基本能力——这时候该考虑应用层分批拉取再比对了。
