not in遇null失效是sql三值逻辑标准行为，因id not in (a,b,null)等价于id!=a and id!=b and id!=null，其中id!=null恒为unknown，致整个条件被where过滤；应改用not exists或left join is null。
NOT IN 遇到 NULL 就失效，这是最常踩的坑
只要子查询或列表里出现 NULL，NOT IN 整个条件直接返回空结果——不是“排除掉 NULL”，而是“啥也不匹配”。这是因为 SQL 中任何与 NULL 的比较（包括 !=、=、IN、NOT IN）都判定为 UNKNOWN，而 WHERE 只接受 TRUE。
常见错误场景：
- 从用户表查“没下过单的用户”，但订单表
user_id允许为空 → 子查询含NULL - 手写
WHERE id NOT IN (1, 2, NULL)→ 整条语句不报错，但查不到任何行 - 用
LEFT JOIN ... IS NULL替代时漏加ON条件或写错关联字段
安全替代方案：用 NOT EXISTS 或 LEFT JOIN IS NULL
NOT EXISTS 不受 NULL 影响，语义清晰，且通常比 NOT IN 性能更稳（尤其大数据量时）；LEFT JOIN ... IS NULL 更直观，适合多字段关联。
示例：查所有没出现在黑名单里的用户
SELECT u.id, u.name FROM users u WHERE NOT EXISTS ( SELECT 1 FROM blacklist b WHERE b.user_id = u.id );
等价写法（LEFT JOIN）：
SELECT u.id, u.name FROM users u LEFT JOIN blacklist b ON u.id = b.user_id WHERE b.user_id IS NULL;
注意点：
-
NOT EXISTS子查询里必须用相关子查询（即引用外层表），否则变成全表扫描 -
LEFT JOIN后的WHERE必须判断被驱动表的主键或非空字段是否为NULL，不能写成b.id IS NULL（如果b.id允许为空，可能误判） - 若黑名单表有复合唯一键（如
(user_id, reason)），NOT EXISTS更易控制逻辑
真要用 NOT IN？先过滤 NULL
如果业务强依赖 NOT IN（比如动态拼接白名单 ID 列表），必须确保子查询结果不含 NULL。
安全写法：
SELECT * FROM orders WHERE user_id NOT IN ( SELECT user_id FROM blacklist WHERE user_id IS NOT NULL );
或者对硬编码列表做清理：
WHERE id NOT IN (1, 2, 3) -- 手动确认不含 NULL
但要注意：
- 用程序生成 ID 列表时，务必提前
filter(None, ids)或类似操作 - PostgreSQL 和 MySQL 对空子查询处理不同：MySQL 返回空集，PostgreSQL 报错
more than one row returned by a subquery—— 所以带聚合或去重时要加GROUP BY或DISTINCT -
NOT IN在索引列上无法走索引范围扫描，而NOT EXISTS通常可以利用被驱动表的索引
别忽略空结果集和类型隐式转换
子查询返回空结果时，NOT IN 行为正常（相当于 “不在一个空集合里”，恒为真）；但一旦混入类型不一致数据，比如把字符串 ID 和整数 ID 比较，某些数据库会静默转类型导致意外命中或漏查。
典型问题：
-
user_id是VARCHAR，子查询却选了CAST(id AS CHAR)或拼接了空格 → 匹配失败 - MySQL 中
'1 ' != '1'，但NOT IN ('1 ', '2')可能漏掉值为'1'的行 - Oracle 对字符长度敏感，
CHAR(10)和VARCHAR2(10)比较时自动补空格，NOT IN易出错
检查方法：单独运行子查询，用 SELECT LENGTH(col), DUMP(col) 看实际值和类型。
