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 基本写法和常见失效原因
直接用 NOT IN 排除数据，最常踩的坑是子查询结果里含 NULL——只要子查询返回任意一个 NULL，整条 NOT IN 就会返回空结果集，不是你想要的“排除”，而是“全丢”。这是因为 SQL 中 value NOT IN (1, 2, NULL) 等价于 value != 1 AND value != 2 AND value != NULL，而 value != NULL 永远为 UNKNOWN，导致整个条件不成立。
实操建议：
- 务必先确认子查询是否可能返回
NULL：检查字段是否允许为NULL，或加WHERE column_name IS NOT NULL - 若无法控制子查询数据，改用
NOT EXISTS更安全（它天然忽略NULL关系） - 简单测试：运行子查询单独看结果，留意是否有
NULL行
NOT IN 和 NOT EXISTS 的性能与语义差异
NOT IN 要求子查询结果必须是确定、非空的离散值集合；NOT EXISTS 则基于相关子查询做逐行判断，语义更清晰，也更容易利用索引。
实操建议：
- 当子查询来自大表且目标字段有索引时，
NOT EXISTS通常更快，尤其在 Oracle / PostgreSQL 中 - MySQL 5.7+ 对
NOT IN有优化，但遇到NULL仍会退化，不推荐依赖 - 示例对比：
SELECT * FROM orders WHERE customer_id NOT IN (SELECT id FROM customers WHERE region = 'CN');
→ 若customers.id允许为NULL，且某行region = 'CN'但id IS NULL，则这条NOT IN不返回任何订单
替代方案：用 LEFT JOIN + IS NULL 更可控
这是绕过 NULL 陷阱、同时兼顾可读性和执行计划稳定性的常用手法。本质是把“不在集合中”转化为“左连接失败”。
实操建议：
- 写法固定：
SELECT t1.* FROM table1 t1 LEFT JOIN table2 t2 ON t1.key = t2.key WHERE t2.key IS NULL - 确保
JOIN条件字段类型一致（比如都是INT，避免隐式转换导致索引失效） - 如果
table2需要带过滤条件（如只排除已删除用户），必须写在ON子句里，不能写在WHERE—— 否则会把外连接变成内连接
多列 NOT IN 的限制与替代写法
标准 SQL 不支持 (col1, col2) NOT IN (SELECT a, b FROM ...) 这种语法（PostgreSQL 支持，但 MySQL、SQL Server 不支持）。强行用会报错或行为异常。
实操建议：
- MySQL / SQL Server 下，改用
NOT EXISTS配合相关子查询：SELECT * FROM t1 WHERE NOT EXISTS (SELECT 1 FROM t2 WHERE t2.a = t1.col1 AND t2.b = t1.col2) - 或者拼接字符串（仅限数据无分隔符风险时）：
CONCAT(t1.col1, '|', t1.col2) NOT IN (SELECT CONCAT(a, '|', b) FROM t2)—— 但要注意类型隐式转换和性能 - 避免用
IN列表硬编码多值组合，超过几百项就容易触发语法长度限制或执行计划劣化
实际用 NOT IN 前，先查子查询结果里有没有 NULL；没有就放心用，有就得换。多列场景基本没得选，只能上 NOT EXISTS 或 LEFT JOIN。
