NOT IN 遇子查询含 NULL 时恒为 UNKNOWN 被 WHERE 过滤，导致无结果；NOT EXISTS 不受 NULL 影响，因只判断是否存在行；安全用 NOT IN 需子查询内加 IS NOT NULL 过滤。
NOT IN 遇到子查询返回 NULL 时，整个条件恒为 UNKNOWN，WHERE 只保留 TRUE 行，所以“一条都不匹配”——不是没删、没查，而是全被静默过滤掉了。
NOT IN 实际执行的是 AND 链式比较
当你写 WHERE id NOT IN (SELECT user_id FROM orders)，数据库底层等价于：
id != value1 AND id != value2 AND id != value3 AND ...
只要子查询里任意一行的 user_id 是 NULL，就会出现 id != NULL 这一项。而 SQL 中任何值与 NULL 比较（=、!=、IN、NOT IN）都返回 UNKNOWN。
AND 表达式中只要有一个 UNKNOWN，整个结果就是 UNKNOWN；WHERE 子句只接受 TRUE，UNKNOWN 和 FALSE 一样被丢弃。
常见误判现象：
- 子查询手动执行能看到 5 条非空 ID，但塞进
NOT IN后查不到任何数据 - 子查询返回空集（0 行）时反而能查出全部数据，和含
NULL的行为完全相反 -
EXPLAIN显示执行计划正常，但实际结果为空——不是崩溃，是逻辑被三值逻辑吃掉了
为什么 NOT EXISTS 不受影响
NOT EXISTS 不做值比较，只判断子查询是否「能返回至少一行」。
它天然跳过 NULL 对关联的影响：即使 user_id 是 NULL，只要 WHERE u.id = o.user_id 这个等值条件不成立，子查询就返回空集，NOT EXISTS 就为 TRUE。
关键实操要点：
- 必须写成相关子查询：
WHERE NOT EXISTS (SELECT 1 FROM users u WHERE u.id = o.user_id)，漏掉u.id = o.user_id就变成全表扫描 - 原
NOT IN子查询里的过滤条件（如status = 'active'）必须平移进子查询的WHERE，不能留在外层 - 子查询里用
SELECT 1，避免查多余字段或触发隐式转换 - 关联字段类型必须一致，否则索引失效（比如一边是
INT，一边是VARCHAR）
强行保留 NOT IN 的唯一安全写法
不是不能用，而是必须显式防御 NULL —— 且只能在子查询内部加 IS NOT NULL。
错误写法：WHERE id IS NOT NULL AND id NOT IN (SELECT user_id FROM orders)（外层加无效）
正确写法：WHERE id NOT IN (SELECT user_id FROM orders WHERE user_id IS NOT NULL)
但要注意：
- 如果业务上
user_id IS NULL有语义（比如表示“匿名下单”），这么过滤会丢数据 - MySQL 对含
WHERE ... IS NOT NULL的子查询可能放弃索引下推，尤其在旧版本中 - COALESCE 转换（如
COALESCE(user_id, -1)）风险高：得确保-1绝对不在合法值范围内，否则误删/误查
最容易被忽略的排查动作
别猜逻辑，先单独跑子查询：
SELECT user_id FROM orders LIMIT 100;
一眼就能看到有没有 NULL。这个动作比调半天执行计划更直接、更省时间。
真正麻烦的从来不是语法怎么写，而是你根本没想到子查询里混进了 NULL——尤其当子查询来自 LEFT JOIN、视图、或允许为空的外键字段时。
