NOT IN遇NULL返回空结果是SQL-92三值逻辑标准行为：子查询含NULL时，WHERE条件恒为UNKNOWN，而WHERE仅保留TRUE行；应改用带关联条件的NOT EXISTS。
NOT IN 遇 NULL 为什么整条查询返回空结果
因为 NOT IN 在子查询结果中包含 NULL 时，整个 WHERE 条件求值为 UNKNOWN，而 SQL 的 WHERE 子句只保留 TRUE 行——UNKNOWN 和 FALSE 都被过滤掉，结果集自然为空。
这不是数据库 bug，是 SQL-92 标准定义的三值逻辑行为。语句 WHERE id NOT IN (1, 2, NULL) 实际等价于：
WHERE id != 1 AND id != 2 AND id != NULL
而 id != NULL 永远是 UNKNOWN，导致整个表达式为 UNKNOWN。
- 常见触发点：LEFT JOIN 后取右表字段（没匹配时为
NULL） - 子查询字段未加
NOT NULL约束，实际存了NULL - 子查询里显式写了
UNION SELECT NULL
NOT EXISTS 为什么能绕过 NULL 问题
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) - 原
NOT IN子查询里的其他条件（如status = 'failed'）必须一并挪进子查询的WHERE中，否则语义偏移
LEFT JOIN + IS NULL 方案要注意什么
这个方案把「不在集合中」转译为「左连接失败」，语义直观，但容易在两个地方出错：
-
ON条件写错（比如漏掉表别名，写成o.user_id = user_id而非o.user_id = u.id），可能触发全表扫描 - 把本该在
ON里的关联条件错放到WHERE，导致LEFT JOIN变成INNER JOIN，丢失预期语义 - 右表有重复匹配行时，会产生笛卡尔膨胀；此时
NOT EXISTS更安全
示例正确写法：SELECT u.* FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE o.user_id IS NULL
如果非要保留 NOT IN，该怎么补救
唯一安全的补救方式是在子查询中显式过滤 NULL：WHERE col IS NOT NULL。但这会改变原始语义：
- 你本想排除所有匹配值（含
NULL），现在只排除非空匹配值 - 若业务上
NULL有明确含义（比如“未知部门”），硬过滤可能掩盖数据质量问题 - 子查询若本身返回空集（0 行），
NOT IN反而会返回全部主表数据——这个反直觉行为和NULL无关，但常被一起误判
真正容易被忽略的点不是语法怎么写，而是：改用 NOT EXISTS 后仍出错，往往是因为忘了把原子查询里的过滤条件（比如时间范围、状态码）一并挪进子查询的 WHERE 中。
