NOT IN 遇 NULL 返回空结果是 SQL 三值逻辑必然行为，因 id NOT IN (1,2,NULL) 等价于 id!=1 AND id!=2 AND id!=NULL，而 id!=NULL 恒为 UNKNOWN，WHERE 只保留 TRUE 行，故全被过滤。
NOT IN 遇到 NULL 为什么会返回空结果
直接用 NOT IN 排除数据时，如果子查询结果里包含 NULL，整个条件永远判为 UNKNOWN，导致查不到任何行——这不是 bug，是 SQL 三值逻辑（TRUE/FALSE/UNKNOWN）的必然结果。比如：WHERE id NOT IN (1, 2, NULL) 等价于 id != 1 AND id != 2 AND id != NULL，而 id != NULL 永远不成立（只能用 IS NOT NULL 判断）。
安全写法：用 NOT EXISTS 替代 NOT IN
NOT EXISTS 天然规避空值问题，语义也更清晰：「找不出匹配记录的主表行」。它只关心子查询是否返回行，不依赖值比较，因此不受 NULL 干扰。
示例（排除已停用用户）：
SELECT u.id, u.name FROM users u WHERE NOT EXISTS ( SELECT 1 FROM blacklisted b WHERE b.user_id = u.id );
- 子查询中
b.user_id为NULL时，b.user_id = u.id为UNKNOWN，整行不匹配，不影响外层判断 - 比
NOT IN更易加索引（可走user_id字段索引） - 若子查询需关联多字段，
NOT EXISTS写法依然稳定；NOT IN多列组合会更复杂且同样怕空
非要保留 NOT IN？必须显式过滤 NULL
如果因历史原因或 ORM 限制必须用 NOT IN，子查询里必须剔除 NULL 值，否则结果不可信。
错误写法（看似合理，实际危险）：
SELECT * FROM orders WHERE customer_id NOT IN ( SELECT customer_id FROM returns );
正确写法（强制排除空）：
SELECT * FROM orders WHERE customer_id NOT IN ( SELECT customer_id FROM returns WHERE customer_id IS NOT NULL );
- 漏掉
WHERE customer_id IS NOT NULL是最常见疏忽 - 即使源表该字段声明为
NOT NULL，也要检查视图、CTE 或 JOIN 后是否引入了NULL - 注意：如果子查询结果为空（0 行），
NOT IN ()会返回全部主表数据——这有时是预期行为，但容易被忽略
性能与可读性权衡点
NOT IN 在小数据集、确定无空值时写起来快；NOT EXISTS 在大多数场景下更可靠、更容易优化。但有个关键例外：
- 当子查询结果极小（如固定几个 ID），且明确不含
NULL，用NOT IN (1, 2, 3)反而比NOT EXISTS更直观、执行计划更简单 - PostgreSQL 14+ 和 MySQL 8.0+ 对
NOT IN的空值处理有优化提示，但不改变语义，仍需人工防御 - SQL Server 中，若子查询含
NULL且未过滤，执行计划可能意外走全表扫描——不是因为逻辑错，而是优化器放弃使用索引
真正难防的不是语法，是那个藏在子查询中间某次 LEFT JOIN 里的隐式 NULL。
