NOT IN 遇到 NULL 返回空结果，因三值逻辑中 30 NOT IN (10,20,NULL) 展开为 NOT (false OR false OR UNKNOWN) → UNKNOWN，WHERE 仅保留 TRUE 行。
NOT IN 遇到 NULL 就查不到数据，不是 bug，是 SQL 标准的三值逻辑在起作用——只要子查询结果里有一个 NULL，整个 NOT IN 条件就永远为 UNKNOWN，而 WHERE 子句只接受 TRUE 的行。
为什么 NOT IN (10, 20, NULL) 等价于全 false
SQL 中的布尔逻辑不是 true/false 二选一，而是 true/false/unknown 三值。任何值与 NULL 比较（包括 =、!=、IN、NOT IN）结果都是 UNKNOWN。
假设主表某行 deptno = 30，子查询返回 (10, 20, NULL)，那么：
-
30 NOT IN (10, 20, NULL)展开为NOT (30 = 10 OR 30 = 20 OR 30 = NULL) - 其中
30 = 10→ false，30 = 20→ false，30 = NULL→UNKNOWN -
false OR false OR UNKNOWN→UNKNOWN -
NOT UNKNOWN→ 还是UNKNOWN -
WHERE只保留TRUE行，UNKNOWN被丢弃 → 这行不返回
所有主表行都经历同样过程，最终结果集为空。
如何快速验证子查询是否含 NULL
别猜，直接查：
SELECT COUNT(*) FROM (your_subquery) t WHERE t.column_name IS NULL;
常见高危场景包括：
- 子查询用了外连接（
LEFT JOIN）后未过滤右表字段 - 子查询字段本身允许
NULL，且业务逻辑没做排空（比如SELECT manager_id FROM employees） - 聚合查询中用了
MAX()/MIN()但源数据全为NULL
绕过 NULL 的三种可靠写法
核心原则：避开 NOT IN 对 NULL 的敏感性，改用语义更清晰、行为更确定的替代方案。
- 用
NOT EXISTS（推荐）：它只关心子查询是否返回行，不比较值，天然免疫NULLSELECT * FROM customers c<br>WHERE NOT EXISTS (<br> SELECT 1 FROM orders o WHERE o.customer_id = c.customer_id<br>);
- 显式排除
NULL：在子查询里加WHERE column IS NOT NULLSELECT * FROM customers<br>WHERE customer_id NOT IN (<br> SELECT customer_id FROM orders WHERE customer_id IS NOT NULL<br>);
- 用
LEFT JOIN ... IS NULL：把“不在集合中”转为“左连接失败”SELECT c.* FROM customers c<br>LEFT JOIN orders o ON c.customer_id = o.customer_id<br>WHERE o.customer_id IS NULL;
NOT IN 和 NOT EXISTS 不只是 NULL 问题
即使子查询确认无 NULL，也建议优先用 NOT EXISTS：
- 语义更贴近“是否存在匹配”，避免隐式类型转换风险（比如子查询返回字符串，主列是数字）
- 多数数据库对
NOT EXISTS能更好利用索引，尤其当子查询带关联条件时 -
NOT IN在子查询结果为空时会返回全部主表行（因为NOT IN ()视为恒真），而NOT EXISTS行为稳定
真正容易被忽略的点是：这个陷阱不会报错、不抛警告、不提示性能问题——它只是安静地返回空结果集，直到你核对业务数据才发现漏了关键记录。
