not in遇null导致where条件恒为unknown而被过滤，故返回空集；这是sql三值逻辑标准行为，非语法错误或数据库bug，正确做法是用not exists或在子查询中加is not null。
NOT IN 遇到 NULL 为什么整条 WHERE 条件不成立
不是语法错，也不是 MySQL 的 bug，是 SQL 标准里明确定义的三值逻辑（True/False/Unknown）在起作用。当你写 col NOT IN (1, 2, NULL)，MySQL 实际把它展开为：col != 1 AND col != 2 AND col != NULL。而 col != NULL 永远返回 UNKNOWN，不是 TRUE 也不是 FALSE；WHERE 只保留结果为 TRUE 的行，UNKNOWN 被直接过滤掉——所以整条查询返回空集。
子查询里有 NULL 就一定失效吗
是的，只要子查询结果中任意一行的对应字段为 NULL，整个 NOT IN 就会失效。比如：
SELECT * FROM orders WHERE user_id NOT IN (SELECT user_id FROM logs);
如果 logs.user_id 里有一条是 NULL，哪怕 orders 表里有 100 万条匹配记录，结果也是 0 行。
- 这不是数据没查出来，是条件根本没被判定为
TRUE -
IN不受此影响：即使子查询含NULL，col IN (1, NULL)仍可能返回部分结果（因为只要col = 1成立就足够） - 但
NOT IN是“全量排除”，任一比较失败（即返回UNKNOWN），整个逻辑链就断了
怎么快速判断当前 NOT IN 是否安全
执行这条检查语句，看子查询是否返回 NULL：
SELECT COUNT(*) FROM (your_subquery) t WHERE your_column IS NULL;
只要结果 > 0，当前 NOT IN 就不可信。更稳妥的做法是：在所有生产环境的 NOT IN 子查询末尾强制加上 WHERE your_column IS NOT NULL，例如：
- ❌ 危险写法：
user_id NOT IN (SELECT user_id FROM blacklist) - ✅ 安全写法：
user_id NOT IN (SELECT user_id FROM blacklist WHERE user_id IS NOT NULL)
注意：这个 IS NOT NULL 必须加在子查询内部，不能加在外层——外层加只过滤主表，不解决子查询引入 UNKNOWN 的根本问题。
为什么 NOT EXISTS 是更可靠的替代方案
NOT EXISTS 天然绕过 NULL 陷阱，因为它不依赖值比较，而是做存在性判断：
SELECT * FROM orders o WHERE NOT EXISTS (SELECT 1 FROM blacklist b WHERE b.user_id = o.user_id);
即使 blacklist.user_id 是 NULL，只要没有 b.user_id = o.user_id 这一匹配行，NOT EXISTS 就返回 TRUE。它还通常能利用索引加速，执行计划更稳定——尤其当子查询结果较大时，比 NOT IN 更少触发临时表物化和全量嵌套循环。
真正容易被忽略的点是：NOT IN 的“失效”不是报错或警告，它静默地返回空结果，而业务逻辑往往默认“没数据 = 没匹配到”，没人会去查执行计划或验证子查询是否含 NULL。
