not in性能崩塌的根本原因是null导致逻辑失效（返回unknown）和执行计划失控（退化全表扫描）；应改用left join+is null，确保右表连接字段非空、有索引，并将子查询条件移至on子句。
NOT IN 查询性能崩塌，根本不是“语法慢”，而是它在 MySQL 里极易触发全表扫描 + 语义失效双重陷阱——只要子查询结果里有一个 NULL，整个条件就变成 UNKNOWN，WHERE 恒不成立，结果为空；同时优化器放弃索引下推，EXPLAIN 里常出现 type: ALL、key_len: NULL、Extra: Using where; Using join buffer。
为什么 NOT IN 遇到 NULL 就查不到数据？
这不是 bug，是 SQL 标准行为：NOT IN 对任何值与 NULL 的比较都返回 UNKNOWN，而 WHERE 只接受 TRUE 行。所以只要子查询中任意一行的连接字段为 NULL（比如 SELECT id FROM customers 里有一条 id IS NULL），整条 WHERE 条件就永不满足。
-
SELECT * FROM orders WHERE customer_id NOT IN (SELECT id FROM customers)—— 若customers.id含NULL，永远返回空集 - 你加了索引也没用：MySQL 优化器不敢把索引下推进子查询，怕语义出错，宁可全表扫
- 线上查不到数据 + 执行时间长，八成是这个原因，而非数据量大
LEFT JOIN + IS NULL 为什么能绕过 NULL 陷阱？
它把“不在集合中”重写为“左表有、右表没匹配上”，语义明确，且不依赖布尔三值逻辑。但必须严格满足几个硬性前提，否则逻辑错或更慢：
- 连接字段必须是等值匹配，如
ON o.customer_id = c.id，不能加函数、CAST 或表达式 - 右表连接字段（如
c.id）必须有索引；若允许NULL，得在ON中显式排除：AND c.id IS NOT NULL - 原子子查询里的过滤条件（如
status = 'inactive'）必须挪进ON子句，不能留在WHERE，否则外连接变内连接 -
WHERE里只能写c.id IS NULL，写成c.id = 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 或 eq_ref；用 SELECT SQL_NO_CACHE 测真实耗时；核对结果行数是否一致，尤其注意右表含 NULL 时两者的语义差异。
