NOT EXISTS 比 LEFT JOIN + IS NULL 更可靠，因其不依赖匹配数量、不受NULL干扰；必须在子查询中正确关联外层表并建立合适索引，否则易全表扫描或逻辑错误。
NOT EXISTS 比 LEFT JOIN + IS NULL 更可靠
用 LEFT JOIN 配合 IS NULL 排除关联记录，表面看能工作，但一旦被关联表有重复匹配、或关联字段含 NULL，结果就不可信。比如 orders 关联 returns 时，一个订单退了两次，LEFT JOIN 会生成两行，哪怕加 GROUP BY 也容易漏判。而 NOT EXISTS 是逻辑否定：只要子查询**至少找到一条匹配**，整行就被排除，不关心数量，也不受 NULL 干扰。
实操建议：
- 永远优先用
NOT EXISTS替代LEFT JOIN ... IS NULL做“不存在”判断 - 子查询里必须关联外层表（如
WHERE r.order_id = o.id），否则变成全表扫描或恒真/恒假 - 被排除的条件写在子查询的
WHERE里，不是主查询——这点初学者常反着写
子查询里别漏写关联条件，否则结果全错
NOT EXISTS 的子查询如果没写对外层表的引用，就会退化成“是否存在任意一条满足条件的记录”，等价于 EXISTS (SELECT 1 FROM t WHERE ...) —— 这时要么全排除，要么全保留，和本意完全相反。错误示例：NOT EXISTS (SELECT 1 FROM returns r WHERE r.status = 'approved')，它根本不看当前订单，只查整个 returns 表有没有已批准退货。
正确写法必须带关联：
SELECT o.* FROM orders o WHERE NOT EXISTS ( SELECT 1 FROM returns r WHERE r.order_id = o.id AND r.status = 'approved' );
常见错误现象：NOT EXISTS 返回空结果，或返回全部数据，十有八九是这里漏了 r.order_id = o.id。
性能关键：被排除表要有合适索引
NOT EXISTS 的子查询对每行外层数据都会执行一次，如果被排除表（如 returns）没在关联字段和过滤字段上建索引，就会触发全表扫描，慢得明显。比如上面例子，returns(order_id, status) 的联合索引比单列 order_id 索引更高效，因为能直接定位到 order_id = ? AND status = 'approved' 的记录，不用回表。
检查方式：
- 用
EXPLAIN看子查询是否走了type=ref或更好，避免type=ALL - PostgreSQL 可加
/*+ IndexScan(r returns_order_status_idx) */强制走索引（需确认优化器支持） - MySQL 8.0+ 注意子查询是否被物化（
materialized），有时反而变慢，可加NO_MERGE提示
和 NOT IN 的区别：NULL 值会让 NOT IN 直接失效
如果被排除字段（如 returns.order_id）允许为 NULL，用 NOT IN (SELECT order_id FROM returns) 会导致整个查询返回空——因为 NULL 参与比较时结果是 UNKNOWN，而 NOT IN 要求所有比较都为 TRUE 才保留该行。这是 SQL 三值逻辑最坑人的地方。
NOT EXISTS 完全不受影响，它只关心“是否存在满足条件的非空匹配”，NULL 字段在子查询 WHERE 里天然被过滤掉。
所以：只要被排除表的关联字段可能为 NULL，或者你不确定，就别碰 NOT IN，直接上 NOT EXISTS。
最容易被忽略的是子查询里的关联条件是否真的生效——改个字段名、少个表别名、跨 schema 没加前缀，都会让 NOT EXISTS 变成无意义的全表扫描或逻辑错误。上线前务必用小数据集验证结果行数，并用 EXPLAIN 看执行计划。
