先说结论：在查找孤立记录的场景里，NOT EXISTS 通常比 LEFT JOIN + IS NULL 快得多。原因很简单——前者用半连接机制，找到第一个匹配就停，内存占用低；后者得先做完全量连接再过滤，一旦右表没索引，直接退化成嵌套循环全表扫描。这不是什么玄学，是执行计划的物理差异。
LEFT JOIN + IS NULL 为什么在大表上会变慢
不是语法有问题，是执行逻辑天生就吃资源。LEFT JOIN 必须先把左表和右表做全量连接，生成一个中间结果集，然后再从中过滤出 c.id IS NULL 的行。这意味着数据库要为左表的每一行，都去右表里找一遍匹配——哪怕你只想要“没匹配上的”那些行，它也得把所有匹配尝试跑完。当右表有千万级数据、又没有索引时，这一步直接退化成嵌套循环加全表扫描。
EXPLAIN里看到Type: ALL或Extra: Using where; Using join buffer，就是典型的危险信号。- 内存压力也不小：JOIN 的中间结果集大小至少等于左表行数，如果右表字段多，实际内存占用可能翻倍。
- 更麻烦的是，在 MySQL 5.7 及更早版本中，
IS NULL条件即使字段有索引也走不了，必须靠FORCE INDEX或改写语句才能触发索引。
NOT EXISTS 为什么通常更快
NOT EXISTS 的本质是半连接（Semi Join）：对左表每行只查“是否存在一个匹配”，找到第一个就停。它不构造中间结果集，也不关心右表到底有多少行匹配——这对“找孤儿”这个场景来说，简直是精准打击。
- 执行计划中间出现
NESTED LOOPS ANTI或INDEX RANGE SCAN，说明已经走了高效路径。 - 子查询里用
SELECT 1比SELECT *轻量，而且不会因为右表字段变更导致隐式重编译。 - PostgreSQL 和 SQL Server 对
NOT EXISTS的优化已经相当成熟；MySQL 8.0+ 也支持等价转换，但旧版本仍然需要手动改写。
索引建不对，两种写法一样慢
孤立记录查询慢，90% 是索引问题，不是写法问题。关键不是“建不建索引”，而是建在哪、建什么类型。
- 右表关联字段（比如
customers.id）必须有主键或唯一索引——这是IS NULL能走索引的前提。 - 左表外键字段（比如
orders.customer_id）也要单独建索引，否则 LEFT JOIN 时左表无法快速定位右表候选行。 - 复合外键（比如
(product_id, store_id)）必须建联合索引，顺序要和ON条件一致，不能只给单字段索引。 - 别只看
EXPLAIN的key字段非空就放心——用EXPLAIN ANALYZE（PostgreSQL）或EXPLAIN FORMAT=JSON（MySQL 8.0+）才能确认实际是否走了索引。
WHERE 里写错条件会让 LEFT JOIN 彻底失效
一个常见的坑：把右表过滤条件塞进 WHERE，比如 WHERE c.status = 'active' AND c.id IS NULL。结果就是查不出任何行——因为 c.id IS NULL 和 c.status = 'active' 不可能同时成立，LEFT JOIN 的语义被悄悄覆盖成了 INNER JOIN。
- 业务过滤条件必须放在
ON子句里：LEFT JOIN customers c ON o.customer_id = c.id AND c.status = 'active'。 - 如果需要同时查“未匹配”和“匹配但状态不合法”两类孤儿，得用
UNION ALL拆开处理，不能硬塞在一个 WHERE 里。 - 字段别名混淆也会触发类似问题：写成
WHERE id IS NULL却没加表前缀，可能被解析成左表字段，永远不生效。
最后，真正上线时最容易被跳过的动作是验证右表字段是否真的 NOT NULL。如果 c.id 允许为空，c.id IS NULL 就分不清是“没匹配上”还是“匹配上了但存了 NULL”。这个点不确认，后面所有优化都是在跑偏。
