NOT IN 性能崩塌源于 NULL 导致的三值逻辑（UNKNOWN）与优化器放弃索引下推的双重问题：子查询含 NULL 时 WHERE 永不满足，且执行计划退化为全表扫描；LEFT JOIN + IS NULL 可规避但需确保连接字段非空、等值且过滤条件置于 ON 中。
NOT IN 性能崩塌不是语法问题，而是语义陷阱 + 执行计划失控的组合拳——只要子查询结果里有一个 NULL，整条 WHERE 就返回 UNKNOWN，结果集为空；同时优化器放弃索引下推，退化为全表扫描。
为什么 NOT IN 遇到 NULL 就查不到数据
这不是 MySQL 的 bug，是 SQL 标准定义：任何值与 NULL 做 NOT IN 比较，结果都是 UNKNOWN，而 WHERE 只保留 TRUE 行。所以哪怕逻辑上该有结果，只要子查询中任意一行的连接字段为 NULL（比如 SELECT id FROM customers WHERE id IS NULL），整个条件就永不满足。
常见错误现象：
-
SELECT * FROM orders WHERE customer_id NOT IN (SELECT id FROM customers)—— 若customers.id含NULL，永远返回空集 - 加了索引也没用：优化器不敢把索引下推进子查询，怕语义出错，宁可全表扫
- 线上查不到数据 + 执行时间长，八成是这个原因，而非数据量大
EXPLAIN 里看到这些就基本确诊了
执行 EXPLAIN 后，如果出现以下任意一项，大概率是 NOT IN 引发的性能雪崩：
-
type: ALL：优化器放弃所有索引，走全表扫描 -
key_len: NULL：没用上索引的任何一列 -
Extra: Using where; Using join buffer：嵌套循环 + 内存缓冲区兜底，说明已退化 -
rows接近左表总行数：预估扫描量爆炸
注意：key_len 和 rows 比 SQL 写法本身更可信——光看“改写了”没用，必须验证执行计划是否真的变了。
LEFT JOIN + IS NULL 不是万能解药
它确实绕开了三值逻辑陷阱，但写错一个细节，效果可能比 NOT IN 还差：
- 连接字段必须是纯等值，如
ON o.customer_id = c.id，不能加CAST、函数或表达式 - 右表连接字段（如
c.id）必须非空：要么建表时加NOT NULL，要么在ON中显式过滤：AND c.id IS NOT NULL - 子查询里的过滤条件（如
status = 'inactive'）必须挪进ON子句，不能留在WHERE，否则外连接变内连接 -
WHERE里只能写c.id IS NULL，写成c.id = NULL永远不成立 - 若右表结果极小（比如就 3~5 行），MySQL 5.7+ 可能将
NOT IN展开为常量数组，比JOIN更轻量
真正卡住性能的从来不是 NOT IN 这三个字母
而是连接字段有没有索引、是否含 NULL、类型和字符集是否一致——这些细节一错，再标准的写法也救不回来。改完别只看 SQL 顺眼，立刻做三件事：EXPLAIN 看 type 是否从 ALL 变成 ref 或 range，key_len 是否非 NULL，rows 是否大幅下降。漏掉任意一项，都只是假优化。
