SQL中利用JOIN查找A表不存在B表的数据

在SQL开发中，“找出A表有而B表没有的记录”是个经典需求。先说结论：最靠谱的写法就是 LEFT JOIN + WHERE B.id IS NULL。原理不复杂——以A表为左表驱动，逐行尝试与B表匹配；如果某行在B中找不到对应记录，B表的所有字段就会全变成NULL，此时用 IS NULL 一抓一个准。但要注意几个关键细节，否则很容易翻车。

用 LEFT JOIN + IS NULL 筛出A表独有记录

直接上结论：INNER JOIN 和 RIGHT JOIN 都派不上用场，必须用 LEFT JOIN 配合 WHERE B.id IS NULL。这套组合拳是业界公认最可靠、可读性最强、数据库优化器也最容易识别的写法。

为什么这么说？因为它的执行逻辑足够透明：以左表（A表）为驱动，每行都尝试匹配B表；匹配不上时，B表字段全空，再通过 IS NULL 精准过滤。相比其他方案，这个写法的坑最少：

• 别碰 NOT IN (SELECT ...) —— 只要B表的关联列里藏着任何一个NULL，整个结果就会被吞掉，这是SQL三值逻辑的经典陷阱。
• NOT EXISTS 语义上没问题，但某些旧版MySQL或低版本执行计划下，性能可能不如 LEFT JOIN 来得干脆。
• 务必确保 ON 条件里的字段类型和空值处理一致。比如A.id是 INT，B.a_id是 INT UNSIGNED，隐式转换失败时你连错在哪都查不出来。

ON 条件写错会导致结果完全失效

ON 不是过滤条件，它定义的是连接逻辑。很多人习惯把本应放在 WHERE 的过滤条件提前塞进 ON，结果查出错误数据还不自知。

举个例子：想查 “A 表中 status=1 且不在 B 表中的记录”，错误示范是这样的：

SELECT A.* FROM A LEFT JOIN B ON A.id = B.a_id AND A.status = 1 WHERE B.a_id IS NULL

这么写会把A表中 status ≠ 1 的行也拉进来——因为 ON 里的 A.status = 1 只影响连接匹配，并不筛A表本身。正确的写法应该是：

SELECT A.* FROM A LEFT JOIN B ON A.id = B.a_id WHERE A.status = 1 AND B.a_id IS NULL

记住两条铁律：

• ON 只管“怎么连”，WHERE 才管“要哪些”。
• 如果B表有复合主键（比如 (a_id, type)），ON 必须完整匹配所有字段，漏一个就可能触发笛卡尔积。
• MySQL 8.0+ 虽然支持 LATERAL，但日常场景完全没必要，反而增加理解成本。

NULL 值和索引会让 IS NULL 判断变慢？

很多新手担心 B.a_id IS NULL 这个判断本身会慢。其实关键不在 IS NULL，而在于B表的关联字段有没有索引。没有索引时，LEFT JOIN 会让A表每行都去扫一遍B表全表，这才是性能噩梦。

• 给B表的外键字段（比如 a_id）建索引是必要条件，否则查询会指数级变慢。
• IS NULL 在有索引时能走索引（B-tree 索引天然包含 NULL 位置），但前提是该字段允许 NULL。如果字段定义为 NOT NULL，那 IS NULL 永远不成立，查询直接返回空，等于白忙活。
• PostgreSQL 对 IS NULL 有专门的索引支持（比如 CREATE INDEX idx ON b (a_id) WHERE a_id IS NULL），但绝大多数场景下，普通索引就足够了。

用 EXCEPT / MINUS 会更简单？

部分数据库（PostgreSQL、SQL Server）支持 EXCEPT，Oracle 用 MINUS，写起来确实短——一行搞定：

SELECT id FROM A EXCEPT SELECT a_id FROM B

但别被它的简洁迷惑，里面藏着不少硬伤：

• 字段数量、类型、顺序必须严格一致，多一个字段或者类型隐式转换失败就直接报错。
• UNION 类操作默认会去重，如果A表里有重复的 id，结果会少行——而 LEFT JOIN 能忠实保留原始重复记录。
• 无法在结果里同时取A表其他字段（比如 A.name、A.created_at），除非整行 SELECT * 再 EXCEPT，但那时要求所有字段都可比较，实际场景很难满足。

所以除非你只查单字段ID且确定无重复，否则别为了省几个字去换写法。老老实实用 LEFT JOIN + IS NULL，稳。