NOT EXISTS依据子查询是否返回行来决定外层行保留与否，常见误用是子查询未关联外层表导致结果恒定；必须用相关子查询（如B.a_id=A.id），且关联字段需索引；相比NOT IN，它不受NULL影响，语义更可靠。
NOT EXISTS 的执行逻辑和常见误用
NOT EXISTS 不是简单地“取反”，它依赖子查询是否返回任意一行结果来决定外层行是否保留。很多人写成 SELECT * FROM A WHERE NOT EXISTS (SELECT 1 FROM B)，这会导致 A 中所有行要么全保留、要么全丢弃——因为子查询没关联，结果恒定。
正确做法是让子查询引用外层表字段，形成相关子查询。否则语义就错了，且数据库优化器可能无法走索引。
- 必须在子查询的
WHERE条件中显式关联外层表（例如B.a_id = A.id） - 子查询里用
SELECT 1或SELECT NULL即可，内容不重要，只看是否存在 - 避免在子查询中写
SELECT *，虽不报错但语义冗余，部分方言（如 SQL Server）会警告
对比 NOT IN：NULL 值导致的静默失败
当你写 WHERE id NOT IN (SELECT ref_id FROM B)，只要 B.ref_id 里有一个 NULL，整条 NOT IN 就变成 UNKNOWN，结果集直接为空——而 NOT EXISTS 完全不受 NULL 影响。
这是线上最隐蔽的漏数据原因。比如用户表查“没下过单的客户”，若订单表 user_id 允许 NULL，NOT IN 就失效；NOT EXISTS 则始终可靠。
-
NOT IN要求子查询列非空，否则逻辑中断；NOT EXISTS没这限制 - 如果子查询可能返回 NULL，别犹豫，直接换
NOT EXISTS - 即使加了
WHERE ref_id IS NOT NULL，也建议优先用NOT EXISTS，更直观且少一层过滤
性能关键：关联字段必须有索引
NOT EXISTS 的性能不取决于外层表大小，而取决于子查询能否快速判断“某外层值是否存在匹配”。如果子查询的关联条件列（如 B.user_id）没索引，数据库就得对每行外层记录做全表扫描。
举个例子：查“没登录过的用户”，写成 SELECT id FROM users u WHERE NOT EXISTS (SELECT 1 FROM logins l WHERE l.user_id = u.id)，这时 logins.user_id 必须有索引，否则慢得明显。
- 检查执行计划，确认子查询走了
INDEX RANGE SCAN或类似操作 - 外层表字段（如
users.id）通常已有主键索引，不用额外处理 - 如果关联是复合条件（如
l.user_id = u.id AND l.status = 'success'），考虑建联合索引
PostgreSQL / MySQL / SQL Server 的细微差异
主流数据库对 NOT EXISTS 的语义一致，但个别场景写法要留心。比如 PostgreSQL 允许子查询里用 LATERAL 做更复杂的关联，而 MySQL 8.0+ 才支持窗口函数嵌套在 NOT EXISTS 子查询中——不过日常使用基本无感。
真正要注意的是 SQL Server：它不支持在子查询里直接引用外层的 CTE 别名，得把 CTE 提到最外层或改用临时表。例如不能写 WITH u AS (...) SELECT * FROM u WHERE NOT EXISTS (SELECT 1 FROM orders o WHERE o.uid = u.id)，会报 Invalid object name 'u'。
- MySQL 5.7 及以前不支持子查询中用
ORDER BY ... LIMIT，但NOT EXISTS本身不需要排序，一般不影响 - Oracle 对
NOT EXISTS优化极好，甚至能自动重写为反连接（ANTI-JOIN） - 所有方言都不允许子查询里出现
FOR UPDATE或 DML 语句
最容易被忽略的点是关联条件写错方向：比如把 B.a_id = A.id 写成 A.a_id = B.id，字段类型或含义不匹配时可能静默返回空结果。上线前务必用小数据集验证子查询是否真能返回预期的“存在”行。
