NOT IN 遇 NULL 失效因底层转为 != AND 组合，而任何值与 NULL 比较均得 UNKNOWN，致整个条件不成立；应改用带关联条件的 NOT EXISTS 或 LEFT JOIN ... IS NULL。
NOT IN 遇到 NULL 为什么直接失效
因为 NOT IN 在底层等价于一系列 != 的 AND 组合，而任意值与 NULL 做比较（如 5 != NULL）结果都是 UNKNOWN，不是 TRUE 或 FALSE。只要有一个 UNKNOWN，整个 AND 表达式就无法为 TRUE，最终查不到任何数据。
典型现象：两个表结构一致，A 表有 100 条记录，B 表有 20 条，其中 B 表的 id 字段含 NULL，用 SELECT * FROM A WHERE id NOT IN (SELECT id FROM B) 返回空结果——哪怕 A 中大量 id 根本不在 B 的非 NULL 值里。
用 NOT EXISTS 替代时必须写关联条件
NOT EXISTS 不受 NULL 影响，因为它只关心子查询是否返回行，不依赖值比较。但关键点在于：子查询必须通过 WHERE 关联外层表字段，否则会退化成“只要子查询不返回任何行就全选”，逻辑完全错误。
正确写法示例：
SELECT * FROM orders o WHERE NOT EXISTS ( SELECT 1 FROM returns r WHERE r.order_id = o.order_id );
常见错误写法（漏掉关联）：
SELECT * FROM orders o WHERE NOT EXISTS ( SELECT 1 FROM returns r WHERE r.order_id IS NOT NULL -- 错！没连 o，变成“只要 returns 表有任意非 NULL order_id 就全不选” );
- 子查询中必须出现外层表的列（如
o.order_id），且出现在WHERE条件里 - 别名要清晰，避免
orders和returns都用r导致混淆 - 子查询里
SELECT后面写1或*都行，执行器通常忽略实际列，但写1更明确意图
性能差异：NOT EXISTS 通常比 NOT IN 快，但要看索引
数据库优化器对 NOT EXISTS 更容易生成半连接（semi-join）计划，尤其是当子查询字段有索引时；而 NOT IN 在遇到 NULL 时可能放弃使用索引，甚至强制走全表扫描。
不过这个优势不是绝对的：
- 如果子查询结果集极小（比如固定几个值），
NOT IN (1,2,3)反而更轻量 - 若
NOT EXISTS子查询中的关联字段没索引，性能可能比带索引的NOT IN还差 - PostgreSQL 对两者优化较接近；MySQL 5.7 及以前版本对
NOT IN的 NULL 处理尤其脆弱
真要保留 NOT IN，只能手动过滤 NULL
如果你坚持用 NOT IN（例如兼容旧代码、或子查询来自不可控视图），唯一安全方式是显式排除 NULL：
SELECT * FROM customers WHERE id NOT IN ( SELECT id FROM blacklisted WHERE id IS NOT NULL );
但要注意：
- 这个写法仅在子查询本身不包含 NULL 时才等价于差集；如果
blacklisted.id全是NULL，子查询返回空集，NOT IN ()会变成 “所有行都满足”，逻辑翻转 - 多字段差集（如对比 (a,b) 联合值）无法用
NOT IN安全表达，必须用NOT EXISTS或LEFT JOIN ... IS NULL - 某些 ORM 自动生成的子查询可能隐式引入 NULL，此时改写成本高于直接换
NOT EXISTS
差集运算真正可靠的方式只有两种：带关联的 NOT EXISTS，或者 LEFT JOIN 加 IS NULL 判断。前者语义更贴近“不存在”，后者在部分场景下更容易被优化器向量化。NULL 不是边界情况，它是 SQL 三值逻辑的默认成员——绕不开，只能正视。
