NOT IN 遇到子查询含 NULL 时整体条件变为 UNKNOWN 被 WHERE 丢弃，结果为空；应改用 NOT EXISTS（需相关子查询）或 LEFT JOIN + IS NULL（注意 ON/WHERE 位置），若坚持用 NOT IN 则须显式过滤 NULL。
NOT IN 遇到子查询结果中任意一个 NULL，整个 WHERE 条件就变成 UNKNOWN，而 SQL 的 WHERE 只保留 TRUE 行——UNKNOWN 被直接丢弃，结果集自然为空。这不是 bug，是 SQL-92 三值逻辑的强制行为。
NOT IN 实际被展开成 AND 判断，而 col != NULL 永远是 UNKNOWN
语句 WHERE id NOT IN (1, 2, NULL) 在逻辑上等价于：
WHERE NOT (id = 1 OR id = 2 OR id = NULL)
由于 id = NULL 永远返回 UNKNOWN，括号内整体为 UNKNOWN，再套一层 NOT 仍是 UNKNOWN。WHERE 过滤时无视 UNKNOWN，所有行都被排除。
- 常见触发点包括：
LEFT JOIN后取右表字段（没匹配时为NULL） - 子查询字段未加
NOT NULL约束，实际存了NULL - 子查询里显式写了
UNION SELECT NULL
改用 NOT EXISTS 是最稳妥的替代方案
NOT EXISTS 不做值比较，只判断子查询是否返回至少一行，NULL 完全不影响“是否存在”这个布尔判断。
- 必须写成相关子查询：外层字段要出现在子查询的
WHERE中，例如o.customer_id = c.customer_id - 错误写法（常量子查询）：
NOT EXISTS (SELECT 1 FROM orders WHERE customer_id = 101)—— 逻辑错，且无法利用索引 - 子查询中的其他过滤条件（如
status = 'failed'）必须一并挪进子查询WHERE，否则语义偏移
LEFT JOIN + IS NULL 方案容易在 ON 和 WHERE 位置上出错
这个方案把“不在集合中”转译为“左连接失败”，但极易因条件放错位置导致语义改变：
- 关联条件漏写表别名，比如写成
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有明确含义（比如“未知部门”），硬过滤可能掩盖数据质量问题 -
NOT IN子查询若本身返回空集（0 行），反而会返回全部主表数据——这个反直觉行为和NULL无关，但常被一起误判
真正容易被忽略的点不是语法怎么写，而是：改用 NOT EXISTS 后仍出错，往往是因为关联字段类型不一致、隐式转换、或子查询里漏掉了外层引用。
