MySQL中NOT IN遇NULL会静默返回空结果集，因三值逻辑下id != NULL恒为UNKNOWN，导致整个WHERE条件被过滤；应改用NOT EXISTS（需相关子查询）或LEFT JOIN + IS NULL。
MySQL在NOT IN子查询中遇到NULL，不是“查得慢”或“报错”，而是**整条查询静默返回空结果集**——哪怕主表有十万行、子查询只多出一个NULL，WHERE条件就全失效。
NOT IN (1, 2, NULL) 实际等价于 id != 1 AND id != 2 AND id != NULL
SQL用的是三值逻辑（TRUE/FALSE/UNKNOWN），而id != NULL永远是UNKNOWN。只要AND表达式里有一个UNKNOWN，整个条件就是UNKNOWN。WHERE只保留TRUE行，UNKNOWN和FALSE都被过滤掉。
常见错误现象：
- 单独跑子查询能看到数据（比如
SELECT user_id FROM blacklist返回101, 102, NULL） - EXPLAIN显示执行计划正常，type不是
ALL，但实际结果为空 - 把
NOT IN临时换成IN，立刻能查出数据，进一步确认是NULL干扰
NOT EXISTS为什么能绕过这个问题
NOT EXISTS不比较值，只判断子查询是否「一行都查不到」。NULL不影响“是否存在行”这个事实判断，所以天然免疫。
但必须写成相关子查询，否则语义就错了：
- ❌ 错误：
NOT EXISTS (SELECT 1 FROM blacklist WHERE user_id = 101)（常量，没关联外层） - ✅ 正确：
NOT EXISTS (SELECT 1 FROM blacklist b WHERE b.user_id = u.id)（u.id来自外层users表） - 原
NOT IN子查询里的过滤条件（如status = 'banned'）必须一并挪进NOT EXISTS的WHERE里，不能留在外层 - 子查询里用
SELECT 1就够了，别写SELECT *或具体字段
LEFT JOIN + IS NULL 的写法陷阱最多
它把“不在集合中”转译为“左表有、右表没匹配上”，逻辑清晰，但容易因一处写错导致结果错或性能崩：
- ON条件必须严格等值：
ON u.id = b.user_id，不能加函数、CAST或表达式 - 右表连接字段（如
b.user_id）若允许NULL，必须在ON里显式排除：ON u.id = b.user_id AND b.user_id IS NOT NULL，否则IS NULL判断会漏判 - 原
WHERE条件（如blacklist.status = 'banned'）必须写进ON，写在最后的WHERE里会让LEFT JOIN退化成INNER JOIN - WHERE里只能写
b.user_id IS NULL，写成b.user_id = NULL永远不成立
真正容易被忽略的是：即使你确认子查询里没有NULL，也要检查字段类型是否一致、字符集是否匹配、索引是否有效——这些细节一错，NOT EXISTS和LEFT JOIN一样会退化成全表扫描。
