NOT EXISTS是最稳妥方式，因其不受NULL干扰、语义清晰、执行计划可控；需确保子查询关联字段有索引、写SELECT 1、明确关联条件，避免隐式转换和全表扫描。

用 NOT EXISTS 找出表A有但表B没有的记录

这是最常用也最稳妥的方式，尤其当表B有复合主键或需要按多字段匹配时。NOT EXISTS 不受 NULL 值干扰，语义清晰，执行计划通常比 LEFT JOIN + IS NULL 更可控。

常见错误是写成 WHERE col IN (SELECT col FROM B) ——只要 B.col 里有一个 NULL，整个条件就返回空结果，导致漏查。

实操建议：

• 把被检查表（A）放在外层，关联字段必须明确写出，避免隐式类型转换（比如 id 是 INT，而子查询里用了字符串 '1'）
• 子查询中 SELECT 1 就够了，不用 SELECT *，避免额外列拖慢性能
• 确保子查询里的关联条件带索引，否则全表扫描会非常慢

SELECT a.id, a.name 
FROM table_a a 
WHERE NOT EXISTS (
SELECT 1 FROM table_b b 
WHERE b.id = a.id AND b.status = a.status
);

用 EXCEPT（或 MINUS）做集合差运算

EXCEPT 的用法很直接：它是按“整行”来比较两组结果的。也就是说，更适合两边结构一致、字段顺序完全相同，而且只有在“整行内容一模一样”时才算重复的场景。数据库支持上，PostgreSQL 和 SQL Server 可以直接用 EXCEPT，Oracle 对应的是 MINUS，MySQL 则要到 8.0+ 才支持 EXCEPT，更早的版本就只能换个方式实现了。

容易踩的坑：字段类型和顺序必须严格一致。比如 SELECT name, age 和 SELECT age, name 不能直接 EXCEPT；VARCHAR 和 TEXT 在某些引擎里会被判为不兼容。

实操建议：

• 先用 SELECT 分别查出两张表的待比对字段，确认数据类型和长度是否对齐
• 加上 ORDER BY 只影响输出顺序，不影响差集逻辑，但调试时加它更容易肉眼核对
• 如果某字段允许 NULL，EXCEPT 会把 NULL 当作相等值处理——这和多数人直觉一致，但得心里有数

SELECT id, name, updated_at FROM table_a
EXCEPT
SELECT id, name, updated_at FROM table_b;

为什么不用 LEFT JOIN？或者什么时候能用

LEFT JOIN 乍看很直白，用起来却很容易埋坑：只要关联字段里出现 NULL，ON 条件就可能不起作用，结果就是那些原本应该被过滤掉的行，反而被意外保留下来；还有一种常见情况是，表B在同一个主键下存在多条记录，这会带来笛卡尔式膨胀，进一步让 IS NULL 的判断出现误判。

只有满足以下全部条件时，LEFT JOIN 才相对安全：

• 关联字段在表B中是主键或唯一约束（杜绝重复匹配）
• 关联字段在两张表中都 NOT NULL
• 只比对单字段，或所有关联字段都确定无 NULL

否则，宁可多写一行子查询，也别贪图 JOIN 表面简洁。

大数据量时必须注意的性能点

差异核对不是简单 SELECT，而是隐式全表扫描+关联操作。千万级数据下，没索引的 NOT EXISTS 子查询可能跑十几分钟甚至超时。

关键动作只有两个：

• 给子查询中 WHERE 的关联字段建联合索引，顺序要和 ON 条件一致（例如 WHERE b.id = a.id AND b.status = a.status，索引应为 (id, status)）
• 避免在子查询里写 SELECT * 或复杂表达式，尤其是函数调用（如 UPPER(name)），会阻止索引使用

如果只是抽检，先用 LIMIT 100 验证逻辑，再删掉跑全量。别让一次误写的 NOT IN 把生产库拖垮。

《夸克》非常好用的免费AI浏览器

下载APP查看