NOT IN 遇 NULL 返回空结果是 SQL-92 三值逻辑规范行为：子查询含 NULL 时条件恒为 UNKNOWN，WHERE 仅保留 TRUE 行；推荐用 NOT EXISTS 替代，语义清晰、性能优且跨库一致。
NOT IN 遇到 NULL 为什么整条查询返回空结果
因为 NOT IN 在子查询结果中包含 NULL 时，整个 WHERE 条件会求值为 UNKNOWN，而 SQL 的 WHERE 子句只保留 TRUE 行——UNKNOWN 和 FALSE 都被过滤掉，结果集自然为空。
它不是数据库 bug，而是 SQL-92 标准定义的三值逻辑行为。常见触发场景包括：
-
LEFT JOIN后取右表字段（没匹配时为NULL） - 子查询字段未加
NOT NULL约束，实际存了NULL - 子查询里显式写了
UNION SELECT NULL
NOT IN (1, 2, NULL) 实际等价于：id != 1 AND id != 2 AND id != NULL，而 id != NULL 永远是 UNKNOWN，导致整个表达式为 UNKNOWN。
为什么 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) - 原子查询里的其他条件（如
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 里——结果查出来的不是“未关联的记录”，而是“未按条件关联的记录”。
