NOT IN易变慢甚至出错，因其遇NULL返回UNKNOWN导致逻辑失效，且难索引下推；应改用LEFT JOIN+IS NULL，确保右表关联字段有索引、非空，并将子查询条件移至ON子句。
为什么 NOT IN 在 MySQL 里容易变慢甚至出错
直接用 NOT IN 查子查询结果，尤其当子查询返回 NULL 时，整个条件会恒为 UNKNOWN，导致查不到任何数据——这不是慢，是逻辑失效。即使没 NULL，MySQL 也常无法有效利用索引，特别是子查询结果集较大时，会退化成嵌套循环（Nesting Loop），逐行比对。
LEFT JOIN + IS NULL 是更可控的等价写法
把 NOT IN (SELECT id FROM t2) 改成 LEFT JOIN 后判断右表主键是否为 NULL，能强制走索引连接，并且语义清晰、结果确定。关键点在于：右表关联字段必须有索引，且 ON 条件要精确匹配左表字段类型和可空性。
- 原写法：
SELECT * FROM t1 WHERE id NOT IN (SELECT id FROM t2); - 改写后：
SELECT t1.* FROM t1 LEFT JOIN t2 ON t1.id = t2.id WHERE t2.id IS NULL; - 务必确认
t2.id上有索引；如果t2.id允许NULL，而你只关心非空匹配，建议加WHERE t2.id IS NOT NULL在子查询里提前过滤 - 若
t1.id和t2.id类型不一致（比如一个是INT，一个是VARCHAR），隐式转换会让索引失效，需显式CAST或统一建表类型
遇到 DISTINCT 或 GROUP BY 子查询时怎么处理
如果原 NOT IN 的子查询带 DISTINCT 或聚合，直接 LEFT JOIN 可能产生重复行。这时不能简单去掉 DISTINCT，而应把去重逻辑下推到 JOIN 的右表——用派生表或 CTE 预先去重。
- 低效写法：
SELECT * FROM t1 WHERE id NOT IN (SELECT DISTINCT user_id FROM logs); - 推荐写法：
SELECT t1.* FROM t1 LEFT JOIN (SELECT DISTINCT user_id FROM logs) AS tmp ON t1.id = tmp.user_id WHERE tmp.user_id IS NULL; - 注意：MySQL 5.7 不支持在
ON中引用外部列到派生表里做相关子查询，所以必须确保派生表是独立可执行的
EXPLAIN 看得见的差异在哪
用 EXPLAIN 对比两种写法，重点看 type 和 rows 字段：NOT IN 子查询通常显示 DEPENDENT SUBQUERY 或 UNION，rows 常是全表估算值；而 LEFT JOIN 版本若走索引，type 应为 ref 或 eq_ref，rows 更贴近实际扫描行数。
- 执行前必做：
EXPLAIN FORMAT=TRADITIONAL SELECT ...，别只信“看起来差不多” - 如果
LEFT JOIN版本仍出现type: ALL，说明关联字段没走索引，回去检查字段类型、是否被函数包裹、字符集是否一致 -
NOT IN在子查询返回空集时结果为空，而LEFT JOIN版本此时会返回左表全部数据——行为一致，但前提是子查询本身不返回NULL
真正卡住性能的，往往不是语法本身，而是 NULL 值穿透、隐式类型转换、或者索引没落在 JOIN 条件字段上。改写只是第一步，验证才是关键。
