NOT EXISTS是最稳的Anti JOIN写法，因其语义明确（左表某行在右表无匹配）、不依赖右表字段是否允许NULL、能稳定触发NESTED LOOPS ANTI或HASH JOIN ANTI；而NOT IN遇右表任意NULL即返回空结果，LEFT JOIN+IS NULL易因判空字段错误或条件位置不当导致逻辑错误。
NOT EXISTS 是最稳的 Anti JOIN 写法
它不依赖右表字段是否允许 NULL，语义就是“左表某行，在右表里找不到匹配记录”，优化器也最容易把它转成 NESTED LOOPS ANTI 或 HASH JOIN ANTI 执行计划。
常见错误现象：写成 SELECT * FROM users WHERE id NOT IN (SELECT user_id FROM orders)，只要 orders.user_id 里有一个 NULL，结果就全空——这是 SQL 三值逻辑决定的，不是 bug。
实操建议：
- 子查询必须写相关条件，例如
WHERE o.user_id = u.id，漏掉就变成非相关子查询，查的是全表而非逐行判断 - 子查询里用
SELECT 1，别用SELECT *或SELECT NULL，避免额外解析开销 - 确保
orders.user_id有索引；若还要加业务条件（如“近30天”），直接塞进子查询：o.user_id = u.id AND o.created_at >= DATE_SUB(NOW(), INTERVAL 30 DAY)
LEFT JOIN + IS NULL 容易踩的坑
这写法看着直观，但判空字段、条件位置、NULL 容忍度三个地方一错，结果就偏了。
典型翻车场景：想查“没下单的用户”，却写成 SELECT u.* FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE o.id IS NULL——o.id 是主键，不可能为 NULL，这个条件永远不成立。
实操建议：
- 判空必须作用于右表的**连接外键字段**，比如
o.user_id IS NULL（前提是ON u.id = o.user_id） - 右表的业务过滤（如状态、时间）必须写在
ON子句里，不能放WHERE；错放会把左表空匹配行直接过滤掉 - 如果
orders.user_id字段允许NULL（比如没设NOT NULL），那IS NULL就分不清是“没匹配”还是“匹配了但存了NULL”，此时必须换NOT EXISTS
为什么绝对不要碰 NOT IN
它不是不能用，而是太容易被数据现实打脸：只要子查询返回任意一个 NULL，整条 NOT IN 查询结果恒为空。
哪怕你加了 WHERE user_id IS NOT NULL，优化器也很难走索引，执行计划常是 HashAggregate + 全表扫描，大数据量下比 NOT EXISTS 慢好几倍。
实操建议：
- 永远用
NOT EXISTS替代NOT IN，尤其当右表字段无NOT NULL约束时 - 如果右表是多字段联合匹配（比如要同时比对
ipaddr和name），NOT EXISTS天然支持，NOT IN得靠元组，部分数据库不支持或性能差 - 不确定时，先跑
EXPLAIN FORMAT=TREE（MySQL 8.0+）或EXPLAIN ANALYZE（PostgreSQL），确认是否真用了ANTI类型节点
大规模数据下 Anti JOIN 性能关键点
写了 NOT EXISTS 不等于自动高效。它的性能几乎完全取决于子查询能否命中索引。
最容易被忽略的一点：子查询中对关联字段做函数操作，比如 WHERE YEAR(o.created_at) = 2025，会让索引失效，优化器大概率退化成逐行 FILTER 扫描。
实操建议：
- 右表连接字段（如
user_id）必须是单独索引，或复合索引的最左前缀 - 避免在子查询
WHERE中对连接字段使用函数、COALESCE、CAST等操作 - 如果右表连接字段允许
NULL，但业务上“有效匹配”本就不该含NULL，可在子查询里显式加AND o.user_id IS NOT NULL，帮优化器更准确认知选择率
