not in遇null返回空结果是sql-92三值逻辑规范行为：子查询含null时条件恒为unknown，where仅保留true行；推荐用not exists替代，语义清晰、性能优且跨库一致。
NOT IN 子查询只要返回任意一个 NULL，整个 WHERE 条件就恒为 UNKNOWN，而 SQL 的 WHERE 只保留 TRUE 行，UNKNOWN 和 FALSE 都被过滤——结果自然为空。这不是 bug，是 SQL-92 标准定义的三值逻辑行为。
NOT IN (a, b, NULL) 实际怎么算的
它不是简单地“排除 a 和 b”，而是被数据库展开为等价逻辑表达式：id != a AND id != b AND id != NULL。而任何值与 NULL 比较（包括 !=、=、IN、NOT IN）都返回 UNKNOWN；AND 运算中只要有一个操作数是 UNKNOWN，整体结果就是 UNKNOWN。
常见误解是以为 “NOT IN 遇到 NULL 就跳过”，实际是整条判断失效，所有行都被拒之门外。
-
SELECT * FROM orders WHERE order_id NOT IN (SELECT order_id FROM refunds)—— 若refunds.order_id有NULL，哪怕orders里有 100 万条不匹配的记录，也一条不返回 - 子查询显式含
NULL（如SELECT 1 UNION SELECT NULL）同样触发该行为 - LEFT JOIN 后取右表字段（如
o.user_id），没匹配时该字段为NULL，直接污染整个NOT IN结果
为什么 NOT EXISTS 能绕开这个问题
NOT EXISTS 不做值比较，只判断子查询是否「返回至少一行」。只要关联条件能命中某行，就算有结果；没命中，就是空集——NULL 值本身不影响“行是否存在”这个事实判断。
但必须写成相关子查询，否则语义错误：
- ❌ 错误（常量子查询，无关联）：
NOT EXISTS (SELECT 1 FROM orders WHERE customer_id = 101) - ✅ 正确（带外层引用）：
NOT EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.customer_id) - 子查询内原有过滤条件（如
status = 'shipped'）必须一并写进子查询WHERE，不能漏
LEFT JOIN + IS NULL 方案最容易错在哪
这个方案把“不在集合中”转译为“左连接失败”，语义直观，但两个地方极易出错：
- ON 条件写错：比如漏掉表别名，写成
ON u.id = order_id而非ON u.id = o.user_id，可能触发全表扫描甚至笛卡尔积 - 把本该在
ON的条件错放WHERE：例如WHERE o.status = 'cancelled'放在WHERE子句，会把LEFT JOIN强制转成INNER JOIN，导致逻辑完全偏移 - 右表连接字段含
NULL且未在ON中显式排除（如AND o.user_id IS NOT NULL），会导致IS NULL判断失效或漏数据
非要保留 NOT IN，该怎么补救
唯一安全的补救方式是在子查询中加 WHERE col IS NOT NULL 过滤：
SELECT * FROM departments WHERE deptno NOT IN (SELECT deptno FROM employees WHERE deptno IS NOT NULL)
但这会改变原始语义：
- 你本想排除所有匹配值（含
NULL），现在只排除非空匹配值 - 若业务上
NULL有含义（如“部门未知”），硬过滤可能掩盖数据质量问题 - 子查询若本身返回空集（0 行），
NOT IN反而会返回全部主表数据——这个反直觉行为和NULL无关，但常被一起误判
真正容易被忽略的点，不是语法怎么写，而是改用 NOT EXISTS 后仍出错——往往因为关联字段类型不一致、隐式转换、或子查询里漏了关键过滤条件。
