not in 遇到 null 会导致整个条件为 unknown，被 where 过滤掉，故返回空集；not exists 因不依赖值比较而天然规避该问题，且需写成相关子查询并确保字段类型一致。
NOT IN 遇到 NULL 不是“崩溃”，而是整个条件变成 UNKNOWN
这不是数据库出错或 JOIN 失效，是 SQL 标准的三值逻辑在起作用：NOT IN 表达式只要子查询结果里带一个 NULL，整行判断就变成 UNKNOWN，而 WHERE 只保留 TRUE 的行——UNKNOWN 和 FALSE 一样被丢弃。所以你看到“没数据”，其实是所有行都被过滤掉了。
典型错误现象：
- 查“未下单用户”，但
orders.user_id有NULL，结果返回空集 -
EXPLAIN显示执行计划正常，但实际查不到任何记录 - 手动把子查询单独跑出来能看见值，一塞进
NOT IN就失效
为什么 NOT EXISTS 能绕过 NULL 问题
NOT EXISTS 不比较值，只判断子查询是否能返回至少一行。它天然跳过 NULL 参与的关联条件，也不依赖子查询结果集里有没有 NULL。
关键点：
- 必须写成相关子查询：子查询里要有
WHERE把内外表连起来，比如o.order_id = i.order_id - 子查询里用
SELECT 1，别写SELECT *或具体字段 - 原
NOT IN子查询里的过滤条件（如status = 'failed'）要平移进NOT EXISTS的WHERE，不能漏 - 关联字段类型必须一致，否则隐式转换会让索引失效——比如一边是
INT，一边是VARCHAR
LEFT JOIN + IS NULL 也能用，但容易写错语义
把“不在集合中”转成“左表有、右表没匹配上”，逻辑等价，但写法容错率低。
常见翻车点：
- 把原子查询的
WHERE条件留在最后的WHERE子句里，比如WHERE o.customer_id IS NULL AND status = 'inactive'—— 这会强制把LEFT JOIN变成INNER JOIN - 右表连接字段没索引，或允许
NULL，导致全表扫描 + 临时表 - 误写
WHERE c.id = NULL（永远不成立），正确写法只能是WHERE c.id IS NULL - 一对多关系下产生重复行，没加
DISTINCT或GROUP BY
COALESCE 或子查询加 IS NOT NULL 是权宜之计
它们能“绕过”问题，但治标不治本，还可能掩盖数据质量问题。
注意事项：
-
COALESCE必须包在整个子查询外面：NOT IN (COALESCE((SELECT ...), ()))不行，得写成NOT IN (SELECT COALESCE(user_id, -1) FROM orders)—— 但负数可能和真实数据冲突 - 子查询里加
WHERE user_id IS NOT NULL看似简单，但如果业务本就该处理NULL（比如表示“未知客户”），这么过滤反而丢数据 - 这两种写法都可能让优化器放弃索引下推，尤其在 MySQL 中，
NOT IN本身就不容易走索引
真正容易被忽略的是：即使子查询确认无 NULL，NOT IN 在语义和性能上仍弱于 NOT EXISTS —— 它隐含类型转换风险，且优化器对它的路径选择更保守。
