NOT IN性能极差的根本原因是NULL导致语义失效（返回UNKNOWN）和执行计划失控（退化全表扫描）；应改用LEFT JOIN+IS NULL，确保右表连接字段非空、有索引，并将子查询条件移至ON子句。
NOT IN 子查询在 MySQL 中性能极差，根本不是“语法慢”，而是它同时触发了语义陷阱和执行计划失控——只要子查询结果里有一个 NULL，整条查询就返回空集；且优化器几乎从不把索引下推进子查询，常退化为嵌套循环全表扫描。
为什么 NOT IN 遇到 NULL 就查不到数据
这不是 MySQL 的 bug，是 SQL 标准行为：NOT IN 对任意值与 NULL 的比较都返回 UNKNOWN，而 WHERE 只保留 TRUE 行。所以只要子查询中有一行的连接字段为 NULL（比如 SELECT id FROM customers 里存在 id IS NULL），整个条件恒不成立。
-
SELECT * FROM orders WHERE customer_id NOT IN (SELECT id FROM customers)—— 若customers.id含NULL，结果永远为空 - 加索引没用：优化器不敢下推索引，怕语义出错，宁可全表扫
- 线上“查不到数据 + 执行慢”，八成是这个原因，而非数据量大
为什么 EXPLAIN 显示 type: ALL、key_len: NULL
MySQL 对 NOT IN (subquery) 很难做索引下推，尤其当子查询返回行数多、字段无索引、或含 NULL 时。优化器往往放弃使用主表索引，转而对每行都执行嵌套循环比对——这等价于 O(n×m) 复杂度。
- 即使子查询字段有索引，
EXPLAIN里也常出现type: ALL、key_len: NULL、Extra: Using where; Using join buffer -
rows字段接近主表总行数？说明实际没走索引过滤 - 子查询若带
WHERE status = 'inactive'，该条件无法下推，只能先取全量再逐行比对
LEFT JOIN + IS NULL 为什么能绕过陷阱但必须写对
它把“不在集合中”重写为“左表有、右表没匹配上”，语义明确，不依赖三值逻辑。但连接条件和过滤位置稍错一步，结果就错或更慢。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 右表连接字段（如
c.id）**必须有索引**；若允许NULL，得在ON中显式排除：ON o.customer_id = c.id AND c.id IS NOT NULL - 原原子子查询里的过滤条件（如
status = 'inactive'）**必须挪进ON子句**，不能留在WHERE，否则外连接变内连接 -
WHERE里只能写c.id IS NULL，写成c.id = NULL永远不成立 - 示例：
SELECT o.* FROM orders o LEFT JOIN customers c ON o.customer_id = c.id AND c.status = 'inactive' WHERE c.id IS NULL
什么时候 LEFT JOIN 也不比 NOT IN 快
盲目替换可能引入新问题，尤其当：
- 右表结果极小（比如就 3~5 行），MySQL 5.7+ 可能将
NOT IN展开为常量数组，比JOIN更轻量 - 右表连接字段没索引，
LEFT JOIN会触发全表扫描 + 临时表，性能反而更差 - 原查询带
DISTINCT或聚合，LEFT JOIN可能因一对多产生重复行，需补GROUP BY或DISTINCT，增加开销 - MySQL 5.6 及更早版本对
LEFT JOIN ... IS NULL的索引选择不稳定，务必先EXPLAIN
真正卡住性能的从来不是 NOT IN 这三个字母，而是连接字段有没有索引、是否含 NULL、类型和字符集是否一致——这些细节一错，再标准的写法也救不回来。改完别只看 SQL 顺眼，立刻做三件事：EXPLAIN 看 type 是否为 ref 或 range、检查 key_len 是否合理、确认 rows 是否显著下降。
