EXCEPT比NOT IN更可靠，因NOT IN遇NULL时结果为UNKNOWN致误判，而EXCEPT天然忽略NULL、去重且语义清晰；适用数据一致性校验，但需列数类型严格一致，注意排序与性能优化。
EXCEPT 为什么比 NOT IN 更可靠
因为 NOT IN 遇到子查询返回 NULL 时整个条件直接判为 UNKNOWN，结果集变空——这常被当成“没数据”误判，实际是逻辑短路。而 EXCEPT 天然去重、忽略 NULL 参与比较，语义更贴近“找 A 有但 B 没有的记录”。
适用场景：校验主从表同步是否遗漏、灰度发布前后数据一致性、ETL 抽取结果比对。
-
EXCEPT要求左右查询列数、类型严格一致，类型不匹配会报错ERROR: set_op mismatched types - 若只需判断“是否存在差异”，结尾加
LIMIT 1可显著提速（尤其大数据量） - PostgreSQL 支持
EXCEPT ALL保留重复行；MySQL 不支持EXCEPT，得用LEFT JOIN ... IS NULL替代
嵌套子查询里用 EXCEPT 容易漏掉的隐式排序
EXCEPT 结果默认无序，但嵌套在 IN 或 = ANY() 中时，如果外层依赖顺序（比如取第一条），就可能出错。更危险的是：某些旧版 PostgreSQL 在子查询中用 EXCEPT 后再 ORDER BY，优化器可能把排序下推失效。
- 嵌套前显式加
ORDER BY并配LIMIT，例如：(SELECT id FROM t1 EXCEPT SELECT id FROM t2 ORDER BY id LIMIT 1) - 避免把
EXCEPT当作“过滤函数”直接塞进WHERE，比如WHERE x IN (SELECT a FROM t1 EXCEPT SELECT a FROM t2)是安全的；但WHERE x = (SELECT a FROM t1 EXCEPT SELECT a FROM t2)会因多行报错 - 如需稳定顺序，必须在外层包装一层带
ORDER BY的查询，不能依赖子查询内部的ORDER BY
性能卡点：EXCEPT 在大表上为什么慢得像没加索引
因为 EXCEPT 底层要对两个结果集做哈希去重 + 差集计算，不是简单走索引就能跳过扫描。尤其当子查询本身含复杂 JOIN 或函数时，优化器很难下推条件。
- 先确保子查询能走索引：把
EXCEPT拆开，单独跑左右两边，用EXPLAIN看是否都用了索引扫描 - 若只是比主键或唯一字段，改用
NOT EXISTS通常更快，例如：SELECT id FROM t1 WHERE NOT EXISTS (SELECT 1 FROM t2 WHERE t2.id = t1.id) - 临时表缓存中间结果有用但有代价：建
CREATE TEMP TABLE tmp1 AS SELECT id FROM t1再EXCEPT，适合反复比对同一张基表
MySQL 用户别硬套 EXCEPT 语法
MySQL 直到 8.0.31 才支持 EXCEPT，且仅限于 UNION 系列操作符的完整实现。低于这个版本写 EXCEPT 会直接报错 ERROR 1064 (42000)。
- 兼容写法用
LEFT JOIN：SELECT t1.id FROM t1 LEFT JOIN t2 ON t1.id = t2.id WHERE t2.id IS NULL - 注意
LEFT JOIN版本不会自动去重，若t1.id有重复，结果也会重复；需要手动加DISTINCT - 若子查询含聚合或窗口函数，MySQL 的
NOT EXISTS通常比LEFT JOIN更易优化，优先选它
真正难的不是写出 EXCEPT，而是想清楚你比对的到底是“值集合差异”还是“行级快照差异”——前者用 EXCEPT 没问题，后者得考虑时间戳、更新标记甚至 binlog 位点。
