not in 常导致全表扫描，根本原因是其语义要求子查询结果完全物化且需处理null逻辑：任一null即令表达式为false/unknown，迫使优化器放弃索引而选择全表扫描；not exists则通过关联探查可精准利用索引。
NOT IN 为什么常导致全表扫描
根本原因不是 NOT IN 本身“禁止用索引”，而是它的语义强制 MySQL 做两件事：一是子查询结果必须完全物化（全部读出），二是要处理 NULL 值逻辑。只要子查询里任意一行是 NULL，整个 NOT IN 表达式就恒为 FALSE 或 UNKNOWN，所以优化器干脆放弃使用索引，改走保守的全表扫描+逐行比对路径。
常见错误现象：
-
EXPLAIN显示type: ALL、key: NULL，哪怕子查询字段明明建了索引 - 子查询加了
WHERE xxx IS NOT NULL，但外层NOT IN仍不走索引——因为优化器无法在预编译阶段确认子查询结果不含NULL - 数据量稍大（比如子查询返回上万行），查询直接卡住
NOT EXISTS 能用索引的关键在哪
NOT EXISTS 是关联子查询，执行时对外表每行做一次“探查”（correlated lookup），而这个探查动作可以精准命中子表上的索引——只要 WHERE 条件中涉及的列有索引，且没被函数/类型转换干扰。
使用场景和要点：
- 子查询必须写成关联形式，例如
WHERE user_id = a.id，不能写成独立子查询 - 子表被探查的字段（如
user_id）需有单列索引或作为复合索引最左前缀 -
SELECT 1比SELECT *更轻量，但不影响索引使用，只是减少传输开销 - 即使子表有大量
NULL值，也不影响索引探查逻辑，因为NOT EXISTS只关心“是否存在匹配行”，不依赖值是否为空
实际改写时容易踩的坑
把 NOT IN 改成 NOT EXISTS 不是简单替换关键词，结构错一点索引就失效。
错误示例：
SELECT * FROM users WHERE id NOT IN (SELECT user_id FROM events WHERE type = 7);
正确改写：
SELECT * FROM users a WHERE NOT EXISTS (SELECT 1 FROM events b WHERE b.user_id = a.id AND b.type = 7);
关键差异点：
- 子查询里必须出现外表别名（
a.id），否则变成非关联子查询，退化为NOT IN行为 -
AND b.type = 7必须写在子查询内部，不能提到外层WHERE，否则可能触发全表扫描 - 如果
events(user_id, type)有复合索引，顺序必须是(user_id, type)才能覆盖探查；反过来则无效
LEFT JOIN + IS NULL 也是一种可行替代
当 NOT EXISTS 写法受限（比如子查询含聚合或复杂条件），LEFT JOIN 是更可控的备选方案，它天然支持索引下推。
等价写法：
SELECT a.* FROM users a LEFT JOIN events b ON a.id = b.user_id AND b.type = 7 WHERE b.user_id IS NULL;
注意点：
-
ON子句里必须包含所有过滤条件（如b.type = 7），写到WHERE会变成内连接语义 - 要确保
JOIN字段（a.id和b.user_id）类型一致，避免隐式转换导致索引失效 - 如果
events表太大，LEFT JOIN可能产生中间临时表，此时NOT EXISTS的逐行探查反而内存更友好
真正难处理的从来不是语法，而是子查询结果里混着 NULL 还假装自己能走索引——这种假设一碰就碎。
