NOT IN 遇 NULL 返回空结果是 SQL 三值逻辑的正常行为，因 id != NULL 结果为 UNKNOWN，导致整个 AND 表达式为 UNKNOWN 被 WHERE 过滤；NOT EXISTS 和 LEFT JOIN + IS NULL 可规避该问题。
NOT IN 遇到子查询返回 NULL 时查不到任何数据，不是 bug，也不是数据库抽风——是 SQL 标准定义的三值逻辑（true/false/unknown）在严格执行。
NOT IN 的底层展开其实是 AND 链式比较
当你写：
SELECT * FROM users WHERE id NOT IN (SELECT user_id FROM logs);
数据库实际执行的逻辑等价于：
id != val1 AND id != val2 AND id != val3 AND ... AND id != NULL
而任何值与 NULL 比较（=、!=、IN、NOT IN）结果都是 UNKNOWN。UNKNOWN 参与 AND 运算时，只要有一个 UNKNOWN，整个表达式就是 UNKNOWN。WHERE 子句只保留 TRUE 行，UNKNOWN 和 FALSE 全部被丢弃。
- 即使子查询只返回一个
NULL，整条语句也“静默失效” - 即使主表有明确不匹配的行（比如
id = 100），它照样不会出现
常见触发场景包括：
- 子查询用了
LEFT JOIN后取右表字段（没匹配时为NULL） - 字段本身允许
NULL，且业务未做排空（如SELECT manager_id FROM employees） - 聚合函数如
MAX()在全NULL输入时返回NULL
为什么 NOT EXISTS 能绕过这个问题
NOT EXISTS 不做值比较，只判断「子查询是否返回至少一行」。
-
NULL值不影响行是否存在：只要关联条件能命中某行，就算有结果；没命中，就是空集 - 它天然免疫
NULL干扰，语义也更贴近“差集”本意
但必须写成相关子查询，否则逻辑就错了：
- ❌ 错误（常量子查询，无关联）：
WHERE NOT EXISTS (SELECT 1 FROM logs WHERE user_id = 101)
- ✅ 正确（带外层引用）：
WHERE NOT EXISTS (SELECT 1 FROM logs l WHERE l.user_id = u.id)
还要注意：
- 原子查询里的其他过滤条件（如
status = 'failed'）必须一并挪进子查询的WHERE - 子查询里用
SELECT 1就够了，别写SELECT *或具体字段 - 外层表别名不能漏，否则可能触发全表扫描（比如写成
u.id = id而非u.id = l.id）
改用 LEFT JOIN + IS NULL 时最容易踩的坑
这个方案把“不在集合中”翻译成“左连接失败”，语义直观，但两个地方一错就全错：
-
ON条件写错：漏掉表别名（如写成o.user_id = user_id），优化器可能放弃索引，甚至当全表扫描处理 - 把本该在
ON里的关联条件错放到WHERE：会导致LEFT JOIN实际变成INNER JOIN，直接漏掉预期结果
正确写法示例：
SELECT u.* FROM users u LEFT JOIN logs l ON u.id = l.user_id AND l.status = 'failed' WHERE l.user_id IS NULL;
关键点：
- 关联条件和业务过滤都放在
ON里（不是WHERE） -
WHERE l.user_id IS NULL是唯一筛选动作，= NULL永远不成立 - 如果右表有重复匹配（如一个用户多条 failed 日志），会产生笛卡尔膨胀；此时
NOT EXISTS更安全
真正容易被忽略的点，不是语法怎么写，而是：
改完 NOT EXISTS 后仍查不出数据，大概率是因为忘了把原 NOT IN 子查询里的所有 WHERE 条件，完整平移进子查询的 WHERE 中——逻辑偏移了，但 SQL 本身不报错。
