EXCEPT是查找表差异最直接的方式，但要求两表结构完全一致；它天然去重、全字段比对，语义清晰，而JOIN易受NULL、重复键等干扰，结果不可靠。
SELECT <em> FROM table_a EXCEPT SELECT </em> FROM table_b 和 SELECT <em> FROM table_b EXCEPT SELECT </em> FROM table_a 是最直接、开箱即用的方式，但仅当两张表结构完全一致（列数、顺序、类型兼容）且无主键/唯一约束干扰时才可靠。
EXCEPT 为什么比 JOIN 更适合“找差异”
EXCEPT是集合运算，天然去重、按行全字段比对，语义清晰：「A里有但B里没有的完整记录」JOIN需手动指定关联键，一旦存在 NULL、重复主键、多对一关系，结果就不可信（比如一条记录在 B 中出现两次，LEFT JOIN ... IS NULL会漏判）视图封装后可复用：
CREATE VIEW diff_a_minus_b AS SELECT <em> FROM table_a EXCEPT SELECT </em> FROM table_b，后续查SELECT COUNT(*) FROM diff_a_minus_b就知道差多少-
不支持
EXCEPT的 MySQL 用户必须改用NOT EXISTS或LEFT JOIN ... IS NULL，但要注意：- 所有参与比较的字段都要显式写进
WHERE条件，不能依赖* -
NULL值需用IS NOT DISTINCT FROM（PostgreSQL）或三值逻辑绕过（MySQL 用COALESCE(col, 'NULL_PLACEHOLDER')）
- 所有参与比较的字段都要显式写进
视图中处理 NULL 和数据类型不一致的常见坑
EXCEPT把NULL = NULL当作相等，这是标准行为，但容易让人误以为“没差异”——其实只是两行都含 NULL，被当成同一行消掉了如果表 A 的
price DECIMAL(10,2)和表 B 的price DECIMAL(12,4)，某些数据库（如 SQL Server）会拒绝EXCEPT，报错Operand data type decimal is incompatible with except解决方法统一强制转换：
CAST(price AS DECIMAL(12,4))，并在视图定义里写死列顺序不一致？
EXCEPT要求左右两边列数和类型位置严格对应，不能靠名字匹配
错误写法：SELECT id, name FROM a EXCEPT SELECT name, id FROM b→ 类型错位，结果完全不可信
正确写法：显式对齐列名与类型：SELECT id, name FROM a EXCEPT SELECT id, name FROM b
大表场景下性能必须加的限制条件
- 直接
SELECT <em> EXCEPT SELECT </em>在千万级表上可能跑十几分钟甚至 OOM，尤其当字段含TEXT/JSON类型时 - 必须提前过滤无关数据：加
WHERE updated_at > '2026-09-01'或限定业务分区键 - 如果只关心主键差异（比如同步校验），改用主键集合比对更快：
SELECT id FROM a EXCEPT SELECT id FROM b，再用这个结果反查详情 - 视图本身不提速，它只是语法糖；真正影响性能的是底层查询是否能走索引 —— 确保用于
WHERE或JOIN的字段有索引，EXCEPT本身无法利用索引优化
实际执行前先用 EXPLAIN 看执行计划，重点确认有没有出现 Hash Match（SQL Server）或 Temporary table（MySQL）这类高内存操作。
别指望一个视图解决所有问题：结构差异、NULL 语义、大表扫描、类型隐式转换——每个点都可能让结果静默出错。
