not in遇null导致空结果是sql三值逻辑标准行为，因col not in (a,b,null)等价于col!=a and col!=b and col!=null，而col!=null恒为unknown，where只保留true行，故全被过滤。
NOT IN 遇到 NULL 为什么整条 WHERE 变成“不成立”
不是 MySQL 的 bug，是 SQL 标准三值逻辑（True/False/Unknown）的必然结果。NOT IN (a, b, NULL) 在数据库引擎眼里等价于：col != a AND col != b AND col != NULL。而 col != NULL 永远返回 UNKNOWN，不是 TRUE 也不是 FALSE；WHERE 只保留结果为 TRUE 的行，UNKNOWN 被直接过滤掉——所以整条查询返回空集。
实际执行时，NULL 是怎么悄悄混进子查询的
常见来源根本不是业务故意插 NULL，而是字段设计或关联逻辑带来的隐性 NULL：
-
LEFT JOIN后未加WHERE过滤，导致右表字段为 NULL 被带入子查询 - 外键字段允许 NULL（比如
user_id为 NULL 表示匿名下单），又没在子查询里显式排除 - 聚合查询中
GROUP BY字段含 NULL，SELECT DISTINCT也照单全收 - 导入脚本或 ETL 流程把空字符串、占位符（如
'N/A'）错误转成了 NULL
用 NOT EXISTS 替代 NOT IN 为什么能绕过这个坑
NOT EXISTS 不依赖值比较，它只关心子查询是否「返回至少一行」。只要子查询里有 NULL，只要没匹配上，它就自然返回 FALSE（对应外层的 NOT 就是 TRUE），全程不触发任何 != NULL 判断。
对比写法：
SELECT * FROM orders o WHERE o.user_id NOT IN (SELECT user_id FROM blacklist); -- 危险：blacklist.user_id 有 NULL 就全空 <p>SELECT * FROM orders o WHERE NOT EXISTS ( SELECT 1 FROM blacklist b WHERE b.user_id = o.user_id ); -- 安全：NULL 自动被跳过，语义清晰</p>
为什么加 IS NOT NULL 过滤还不够保险
只加 WHERE id IS NOT NULL 能解决 NULL 导致空集的问题，但容易忽略两个隐藏风险：
- 外层字段本身为 NULL 时，
NOT IN依然不命中——比如orders.user_id是 NULL，它既不在黑名单里，也不会被查出来 - 子查询去重失效：若
blacklist有百万行、其中 90% 是重复user_id，MySQL 可能物化成大临时表，拖慢整个查询 - 索引失效：即使加了
IS NOT NULL，NOT IN在单列索引上仍大概率触发全表扫描（优化器判定否定条件选择率低）
真正稳的组合是：NOT EXISTS + 关联字段有索引 + 外层 WHERE 先缩小数据集（比如加时间范围）。
