NOT IN 遇到 NULL 返回空行，因三值逻辑下条件变为 UNKNOWN 而被 WHERE 排除；应改用 NOT EXISTS，并确保关联条件正确、索引有效。
NOT IN 遇到 NULL 为什么直接不返回任何行
因为 NOT IN 在子查询结果中包含 NULL 时，整个条件会变成 UNKNOWN（三值逻辑），而 WHERE 只接受 TRUE 的行——UNKNOWN 被当作不匹配，所以结果为空。这不是 Bug，是 SQL 标准行为。
常见触发场景：
- 子查询字段允许为
NULL（比如外键未约束NOT NULL） - 子查询用了
LEFT JOIN后取右表字段 - 子查询里写了
COALESCE(col, NULL)或显式UNION SELECT NULL
用 NOT EXISTS 替代的写法要点
NOT EXISTS 不受 NULL 影响，因为它只关心子查询是否返回行，不比较具体值。但要注意关联条件必须写对，否则逻辑会错。
正确写法示例（假设查主表 orders 中未被 invoices 关联的订单）：
SELECT o.* FROM orders o WHERE NOT EXISTS ( SELECT 1 FROM invoices i WHERE i.order_id = o.order_id );
关键点：
- 子查询里必须有相关子查询（correlated subquery），即用
WHERE把内外表连起来 - 子查询里用
SELECT 1就够了，别写SELECT *或具体字段 - 外层不能漏掉表别名（如
o.order_id），否则可能误成全表扫描
NOT IN 改 NOT EXISTS 时容易漏掉的细节
很多人以为只是把 NOT IN 换成 NOT EXISTS 就完事，其实语义可能已变。
比如原语句：
SELECT * FROM users WHERE id NOT IN (SELECT user_id FROM logs WHERE status = 'failed');
如果 logs.user_id 有 NULL，该语句返回空；但直接改成：
SELECT * FROM users WHERE NOT EXISTS (SELECT 1 FROM logs WHERE logs.user_id = users.id AND status = 'failed');
这个改写才是等价的——注意子查询里把原 WHERE 条件（status = 'failed'）也带进来了，且用 = 关联主键。
易错点：
- 忘了把原
NOT IN子查询里的WHERE条件平移进EXISTS子句 - 关联字段类型不一致（比如一边是
INT，一边是VARCHAR），导致索引失效或隐式转换 - 子查询里没加
AND连接多个条件，而是错误地写成两个独立WHERE
性能差异和索引建议
NOT EXISTS 通常比 NOT IN 更快，尤其当子查询结果集大时，因为它是「找到一个就短路」；而 NOT IN 往往要生成完整中间结果再逐个比对。
但前提是字段上有合适索引：
- 子查询中的关联字段（如
invoices.order_id）必须有索引 - 如果子查询还有额外过滤条件（如
status = 'paid'），考虑建联合索引，顺序按「关联字段 + 过滤字段」排列 - 避免在
NOT EXISTS子查询的关联条件里用函数，比如WHERE i.order_id = UPPER(o.order_id)，会无法走索引
真正麻烦的是嵌套层级深、又带聚合或窗口函数的子查询——这时候 NOT EXISTS 未必更优，得看执行计划，别无脑替换。
