NOT IN遇NULL返回空结果，因三值逻辑下value NOT IN (1,2,NULL)等价于value!=1 AND value!=2 AND value!=NULL，而value!=NULL恒为UNKNOWN，致整个条件不成立。
NOT IN 为什么查不出 NULL 对应的行
直接用 NOT IN 查“不在某集合中”的数据时，如果子查询或列表里包含 NULL，整条语句会返回空结果——不是逻辑错误，是 SQL 标准定义的行为：value NOT IN (1, 2, NULL) 等价于 value != 1 AND value != 2 AND value != NULL，而 value != NULL 永远为 UNKNOWN，导致整个条件不成立。
常见表现：明明表里有值为 3、4 的记录，但 SELECT * FROM t WHERE id NOT IN (SELECT id FROM s) 却一条不返回，检查发现 s.id 有 NULL。
- 临时排查：加
WHERE id IS NOT NULL到子查询里，比如SELECT * FROM t WHERE id NOT IN (SELECT id FROM s WHERE id IS NOT NULL) - 更稳妥写法：改用
NOT EXISTS，它天然绕过NULL陷阱 - 若用字面量集合（如
NOT IN (1, 2, 3)），确保括号内不含NULL；手写时不会出错，但拼接动态 SQL 时需过滤掉空值
NOT IN 和 NOT EXISTS 性能差异在哪
NOT IN 要求子查询结果先全部计算出来并去重（隐式 DISTINCT），再逐行比对；而 NOT EXISTS 是对外表每行执行一次关联子查询，找到匹配就短路退出。当子查询结果集大、或外表小、或存在有效索引时，NOT EXISTS 通常更快且内存占用更低。
- 如果子查询字段有索引（如
s.id是主键或有索引），NOT EXISTS可走索引查找，NOT IN却可能触发全量扫描+哈希构建 - MySQL 5.7+ 对
NOT IN有部分优化，但遇到NULL仍会退化；PostgreSQL 和 SQL Server 表现类似 - 实操建议：只要子查询涉及表（而非固定列表），优先写成
NOT EXISTS形式
用字面量集合时 NOT IN 的边界情况
写 WHERE status NOT IN ('pending', 'processing') 看似简单，但要注意字段类型和隐式转换风险：
- 若
status是VARCHAR但含尾部空格，而列表里没带空格，可能漏匹配（取决于数据库的 padding 行为，如 MySQL 的ANSI_PADDING OFF） - 若列是
ENUM或INT类型，却传入字符串字面量（如NOT IN ('1', '2')），某些数据库会尝试转换，但结果不可靠——应保持类型一致 - 集合过大（比如几百项）时，部分数据库（如 Oracle）会对
IN/NOT IN列表长度有限制，超出报错ORA-01795: maximum number of expressions in a list is 1000
替代方案：LEFT JOIN + IS NULL 更可控
当需要排除另一张表中存在的记录，且对可读性或执行计划有明确要求时，LEFT JOIN 显式写出关联逻辑，比 NOT IN 或 NOT EXISTS 更容易调试和加索引：
SELECT t.* FROM orders t LEFT JOIN refunds r ON t.order_id = r.order_id WHERE r.order_id IS NULL;
这种写法没有 NULL 陷阱，执行计划清晰，也方便在 ON 条件里加额外过滤（比如只排除已审核的退款记录）。
- 注意：必须用
r.order_id IS NULL判断右表无匹配，不能写成t.order_id != r.order_id（语法错误）或漏掉IS NULL - 如果右表连接字段无索引，性能会明显下降，务必确认
r.order_id已建索引 - 比起
NOT EXISTS，它多返回一列（r.*字段），但实际只用判断是否为NULL，优化器通常能裁剪掉
真正麻烦的从来不是语法怎么写，而是子查询里有没有 NULL、连接字段有没有索引、以及你看到的“空结果”到底是逻辑本该如此，还是被标准悄悄吞掉了。
