EXCEPT是查找表差异最直接的方式，但要求两表结构完全一致；它天然去重、全字段比对，语义清晰，而JOIN易受NULL、重复键等干扰，结果不可靠。

SELECT FROM table_a EXCEPT SELECT FROM table_b 和 SELECT FROM table_b EXCEPT SELECT FROM table_a 是最直接、开箱即用的方式，但仅当两张表结构完全一致（列数、顺序、类型兼容）且无主键/唯一约束干扰时才可靠。

---

EXCEPT 为什么比 JOIN 更适合“找差异”

• EXCEPT 是集合运算，天然去重、按行全字段比对，语义清晰：「A里有但B里没有的完整记录」

• JOIN 需手动指定关联键，一旦存在 NULL、重复主键、多对一关系，结果就不可信（比如一条记录在 B 中出现两次，LEFT JOIN ... IS NULL 会漏判）

• 视图封装后可复用：CREATE VIEW diff_a_minus_b AS SELECT FROM table_a EXCEPT SELECT 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 EXCEPT SELECT 在千万级表上可能跑十几分钟甚至 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 语义、大表扫描、类型隐式转换——每个点都可能让结果静默出错。