NOT EXISTS最稳，能准确表达“主表某条记录在从表中找不到匹配项”，避免NULL干扰和NOT IN的UNKNOWN陷阱；子查询必须关联主表字段并建索引，否则性能断崖下跌。
用 NOT EXISTS 找出主表里缺失关联的记录
直接用 NOT EXISTS 最稳，它能准确表达“主表某条记录，在从表中找不到匹配项”这个逻辑。比 LEFT JOIN ... IS NULL 更不容易被 NULL 值干扰，也比 NOT IN 避开了子查询返回 NULL 导致整个条件恒为 FALSE 的坑。
常见错误现象：NOT IN (SELECT id FROM detail) 一旦 detail.id 里有 NULL，整条语句就查不出任何结果——因为 value NOT IN (1, 2, NULL) 永远是 UNKNOWN，被当作 FALSE 处理。
-
NOT EXISTS只关心子查询是否返回行，不关心值是不是NULL - 子查询里必须关联主表字段，比如
WHERE d.order_id = o.id，否则变成全表扫描 - 记得给从表关联字段建索引，否则性能会断崖式下跌
LEFT JOIN + IS NULL 的写法和陷阱
这个写法直观，但容易在 NULL 处理上翻车。核心是：必须确保 JOIN 条件只依赖关联字段，且 IS NULL 判断的是从表的**被关联字段本身**，不是它的计算结果或别名。
典型错误：LEFT JOIN detail d ON d.order_id = o.id WHERE d.id IS NULL 是对的；但写成 WHERE d.status IS NULL 就可能漏掉本应存在的记录——因为 status 本身允许为 NULL，你分不清这是没匹配上，还是匹配上了但值就是 NULL。
- 始终用从表的主键或非空唯一字段做
IS NULL判断，比如d.id或d.order_id - 如果从表没有合适字段，宁可加个
CASE WHEN d.id IS NOT NULL THEN 1 ELSE 0 END AS matched再过滤 -
LEFT JOIN在大数据量时通常比NOT EXISTS更耗内存，尤其当从表很大但匹配率很低时
什么时候该用 NOT IN？几乎不用
除非你能 100% 确保子查询结果里不含 NULL，否则别碰 NOT IN。它看着最像自然语言，实际最危险。
使用场景极少：比如子查询明确加了 WHERE column IS NOT NULL，且该列在源表上有 NOT NULL 约束，同时你还做了执行计划验证——这种情况下才勉强可用。
-
NOT IN在 PostgreSQL 和 SQL Server 中行为一致，但在 MySQL 早期版本里有额外优化问题 - 即使子查询加了
WHERE x IS NOT NULL，如果优化器没下推该条件，仍可能引入NULL - 如果子查询结果为空（0 行），
NOT IN返回空集，而NOT EXISTS返回全集——语义完全不同
性能差异关键看执行计划
别凭经验猜哪个快，EXPLAIN 看实际走索引还是全表扫描。三个写法在不同数据库、不同数据分布下表现差异很大。
比如 PostgreSQL 对 NOT EXISTS 优化极好，常转成半连接（semi-join）；而 MySQL 8.0+ 对 LEFT JOIN 的物化优化有时反而更快；SQL Server 则对两种都支持得不错，但 NOT IN 几乎总被重写成 NOT EXISTS。
- 先用
EXPLAIN ANALYZE（PostgreSQL）或EXPLAIN FORMAT=JSON（MySQL）看真实执行路径 - 重点观察
Rows估算是否严重偏离实际，以及有没有出现Seq Scan或Using temporary - 如果主表小、从表大，优先试
NOT EXISTS；如果从表有高效覆盖索引，LEFT JOIN可能更优
NOT EXISTS，再根据执行计划微调。最容易被忽略的是子查询里的关联条件漏写或写错字段——一查全表，几秒变几分钟。 
