NOT IN遇NULL返回空结果是SQL三值逻辑标准行为，因id NOT IN (1,2,NULL)等价于id!=1 AND id!=2 AND id!=NULL，而id!=NULL恒为UNKNOWN，致整个条件为UNKNOWN被WHERE过滤；应改用NOT EXISTS或LEFT JOIN+IS NULL。
NOT IN 遇到 NULL 时返回空结果，不是数据库出错，而是 SQL 标准规定的三值逻辑（TRUE/FALSE/UNKNOWN）在严格执行——只要子查询里出现一个 NULL，整个条件就变成 UNKNOWN，而 WHERE 只保留 TRUE 的行。
它实际被展开成一串 AND 判断
比如 id NOT IN (1, 2, NULL)，数据库会等价重写为：
- id != 1 → 可能是 TRUE
- id != 2 → 可能是 TRUE
- id != NULL → 在 SQL 中永远是 UNKNOWN（因为 NULL 表示“未知”，无法确定是否相等或不等）
而 TRUE AND TRUE AND UNKNOWN = UNKNOWN。WHERE 子句会把所有 UNKNOWN 和 FALSE 行都过滤掉，所以没一行能通过，结果集为空。
一个 NULL 就足以让整条语句“静默失效”
哪怕主表里有明确不匹配的值（例如 id = 100），哪怕子查询只返回一个 NULL 行，结果仍是空。这不是性能问题，也不是数据量大导致的延迟，而是逻辑层面直接中断。
这种行为在 MySQL、PostgreSQL、SQL Server、Oracle 中完全一致，是 SQL-92 标准定义的，不是某家的 bug。
为什么 NOT EXISTS 没这个问题
NOT EXISTS 不做值比较，只判断「子查询是否返回至少一行」：
- 有匹配行 → 返回 FALSE
- 无匹配行 → 返回 TRUE
- NULL 值不影响“是否存在行”，所以天然免疫
但必须写成相关子查询，例如：
NOT EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id)
不能写成常量子查询（如 WHERE o.user_id = 101），否则失去关联语义。
LEFT JOIN + IS NULL 也能用，但容易写错
这个方案把“不在集合中”转译为“左连接失败”，语义清晰，但两个细节极易出错：
- ON 条件漏别名：写成 o.user_id = user_id 而非 o.user_id = u.id，可能触发全表扫描
- 过滤条件放错位置：把 status = 'failed' 写在最后的 WHERE 里，而不是 ON 中，会让 LEFT JOIN 退化为 INNER JOIN
正确写法示例：
SELECT u.* FROM users u LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'failed' WHERE o.user_id IS NULL
