NOT EXISTS比NOT IN更可靠，因NOT IN遇右表NULL值时返回空结果集（NULL参与比较恒为UNKNOWN），而NOT EXISTS仅判断子查询是否返回行，完全规避NULL逻辑问题。
NOT EXISTS 为什么比 NOT IN 更可靠
因为 NOT IN 遇到右表字段含 NULL 时会返回空结果集——SQL 中任何与 NULL 的比较（包括 !=、NOT IN）都判定为未知（UNKNOWN），导致整行被过滤掉。而 NOT EXISTS 只关心子查询是否返回行，完全绕过 NULL 值参与逻辑判断的问题。
常见错误现象：SELECT * FROM users WHERE id NOT IN (SELECT user_id FROM orders) 在 orders.user_id 允许为空且实际存在 NULL 时，查不到任何用户，即使大量用户确实没下单。
- 必须确保子查询中关联外层表，例如
WHERE o.user_id = u.id，否则变成非相关子查询，语义错误 - 若右表有复合匹配条件（如需同时比对
ipaddr和name），NOT EXISTS写法自然支持，NOT IN则需用元组（部分数据库不支持或性能差） - 在 MySQL 5.7+、PostgreSQL、SQL Server 等主流引擎中，优化器通常能将
NOT EXISTS转为高效的反连接执行计划
LEFT JOIN + IS NULL 的适用场景和陷阱
这是语义最直白的反连接写法：先保留左表全部记录，再通过 IS NULL 筛出右表无匹配的行。但容易忽略两个关键点：
- 必须在
WHERE中判断右表的**被连接字段**是否为NULL，而不是任意字段；例如WHERE o.id IS NULL是错的，应写WHERE o.user_id IS NULL（假设 ON 条件是u.id = o.user_id） - 如果右表连接条件涉及多个字段（比如
ON a.id = b.a_id AND b.status = 'active'），则IS NULL必须作用于左表能唯一标识匹配的字段（通常是外键），否则可能漏判 - 当右表有索引覆盖连接字段时，该写法性能通常不输
NOT EXISTS；但若连接字段无索引，两者都会全表扫描，此时优化重点应是加索引而非换写法
大规模数据下 NOT EXISTS 的性能调优要点
不是写了 NOT EXISTS 就自动高效——它的性能高度依赖子查询能否走索引。核心原则：让子查询的 WHERE 条件能命中右表的索引前缀。
- 子查询中用于关联的字段（如
o.user_id）必须是右表的索引字段，最好是单独索引或复合索引的最左前缀 - 避免在子查询
WHERE中对关联字段做函数操作，例如WHERE YEAR(o.created_at) = 2025会让索引失效 - 如果右表连接字段允许
NULL，但业务上“有效匹配”其实排除了NULL，可在子查询中显式加AND o.user_id IS NOT NULL，帮助优化器更准确认知选择率 - PostgreSQL 中可配合
EXPLAIN ANALYZE观察是否用了Anti Join执行节点；MySQL 8.0+ 可查EXPLAIN FORMAT=TREE看是否转为Not_exists操作
什么时候不该用 NOT EXISTS
当你要查的是「左表某字段值不在右表某字段值集合中」，且右表该字段确定无 NULL、数据量小（NOT IN 写起来更短，维护成本略低。
但更常见的问题是：右表字段没有 NOT NULL 约束，或者 DBA 会在批量导入时临时禁用约束——这种情况下，NOT EXISTS 是唯一安全选择。
另一个边界情况：右表需要多条件联合判断（如 user_id = ? AND type = 'email' AND is_primary = true），此时 NOT EXISTS 的子查询结构清晰，而强行拼进 NOT IN 需要用元组语法（(user_id, type, is_primary) NOT IN (...)），不仅可读性差，MySQL 直到 8.0.19 才完整支持，且无法利用索引。
