mysql 8.0.31前不支持except，postgresql/sql server原生支持但语义有异；推荐用left join ... where right_table.id is null实现差集，需确保连接字段not null并加on过滤，优先建联合索引，大表务必explain验证性能。
EXCEPT 在 PostgreSQL/SQL Server 里能直接用，MySQL 不行
MySQL 直到 8.0.31 才支持 EXCEPT（且需开启 sql_mode=STRICT_TRANS_TABLES），之前版本一写就报错 ERROR 1064 (42000)。PostgreSQL 和 SQL Server 原生支持，但语义有差异：PostgreSQL 的 EXCEPT 默认去重，SQL Server 的 EXCEPT 也去重且要求列数、类型严格一致。
实操建议：
- 先查数据库版本：
SELECT VERSION(); - 跨数据库迁移时，别硬套
EXCEPT，优先考虑等价的LEFT JOIN ... WHERE right_table.id IS NULL - PostgreSQL 中若需保留重复行，得改用
NOT EXISTS或子查询 +ROW_NUMBER()
LEFT JOIN 判空比 EXCEPT 更通用，但容易漏掉 NULL 安全问题
LEFT JOIN 搭配 WHERE right_table.id IS NULL 是最稳妥的差集写法，兼容所有主流 SQL 引擎。但它有个隐蔽陷阱：如果右表连接字段本身允许 NULL，IS NULL 判定会把“本该匹配却因 NULL 失败”的行也误判为差集结果。
实操建议：
- 连接字段必须是
NOT NULL，否则在ON条件里加非空过滤：ON a.id = b.id AND b.id IS NOT NULL - 避免用
!=或替代IS NULL，NULL 参与任何比较都返回UNKNOWN - 测试时故意往右表插一条
id = NULL的数据，看结果是否突增——这是最快速的 NULL 漏洞验证法
性能差别大：EXCEPT 通常走哈希或排序，LEFT JOIN 可走索引
EXCEPT 内部一般触发去重 + 排序，即使两表都有索引，也可能放弃使用，转而建临时哈希表。而 LEFT JOIN 如果连接字段有索引，优化器大概率走 Index Nested Loop，尤其当左表小、右表大时，性能差距可达数量级。
实操建议：
- 对大表做差集前，先
EXPLAIN对比两种写法的执行计划，重点看是否出现Using temporary; Using filesort - 确保
JOIN字段上有联合索引，比如差集基于(user_id, status)，就建INDEX idx_user_status ON table_b(user_id, status) - 如果只是取“是否存在”，用
NOT EXISTS往往比LEFT JOIN更轻量，因为找到第一个匹配就短路
字段顺序和类型不一致会导致 EXCEPT 静默失败或结果错乱
EXCEPT 要求左右查询的列数、类型、顺序完全一致。类型隐式转换可能成功（如 int → bigint），也可能失败（如 varchar(10) vs varchar(50) 在某些模式下截断），更麻烦的是字段顺序错一位——语法合法，结果全错，还很难肉眼发现。
实操建议：
- 写
EXCEPT时，显式写出所有字段名，禁用SELECT *：SELECT id, name FROM a EXCEPT SELECT id, name FROM b - 用
pg_typeof()（PostgreSQL）或SQL_VARIANT_PROPERTY()（SQL Server）检查两边字段实际类型是否一致 - 在开发环境用小数据集跑一遍，再
SELECT COUNT(*)对比：左表行数 − 差集行数 应等于右表中被匹配上的行数（近似验证逻辑）
差集逻辑看着简单，真正卡住人的往往是 NULL 处理、类型隐式转换、索引失效这三块。写完别急着上线，拿真实数据跑一遍 EXPLAIN 和手工抽样比对，比读十遍文档管用。
