not in 不能走索引，因其破坏b+树有序性与范围定位能力，无法导航子树，且遇null语义复杂、类型转换或大列表时进一步失效；应改用left join+is null等可定位逻辑。
因为 NOT IN 会破坏 B+ 树索引的有序性与范围定位能力，优化器无法用树搜索跳过无效数据块，只能退化为全表扫描或全索引扫描。
NOT IN 为什么不能走索引
MySQL 的 B+ 树索引依赖键值的有序排列来快速定位——等值查靠哈希/跳转，范围查靠顺序跳块。但 NOT IN 表达的是“排除若干离散值”，它不构成连续区间，也没有起始/终止边界。优化器没法从根节点开始往下“导航”到一个可跳过的子树区域，只能逐行比对所有记录是否不在列表中。
更关键的是，NOT IN 遇到 NULL 时语义复杂（整个表达式结果为 UNKNOWN），进一步阻碍索引下推。即使列表里没 NULL，优化器也倾向保守处理，直接放弃索引。
哪些情况会让 NOT IN 显式失效
-
NOT IN子查询返回结果含NULL：例如SELECT * FROM user WHERE id NOT IN (SELECT manager_id FROM dept)，只要manager_id有 NULL，整条查询结果为空，且必然不走索引 - 右侧列表过大（如几百个以上值）：优化器可能改用哈希反查，但仍不会走 B+ 树索引
- 字段类型隐式转换：比如
id是INT，但NOT IN ('1','2','3')传字符串，触发类型转换，索引失效 - 联合索引未覆盖全部条件：例如索引是
(status, created_at)，但写成WHERE status NOT IN (0,1) AND created_at > '2023-01-01'，第一个条件就让整个联合索引失效
替代 NOT IN 的可行写法
想保持索引可用，得把逻辑转成“可定位”的形式：
- 用
LEFT JOIN + IS NULL：例如SELECT u.* FROM user u LEFT JOIN black_list b ON u.id = b.user_id WHERE b.user_id IS NULL，只要b.user_id有索引，就能走索引连接 - 用
NOT EXISTS（注意：它也不走索引，但有时比NOT IN更可控；若子查询带有效索引条件，仍可能走内表索引） - 拆成多个
!=并用AND连接（仅限极小固定列表）：如id != 1 AND id != 2 AND id != 3，此时可能走主键索引，但超过 3~5 个值后优化器大概率又放弃 - 业务层预计算白名单 ID，改用
IN查询（最稳，前提是白名单可缓存、更新不频繁）
容易被忽略的细节
很多人以为加了索引就万事大吉，但 NOT IN 的失效不是配置问题，而是 B+ 树结构本身的限制——它天生不适合“反向枚举”。哪怕你给字段建了唯一索引、甚至主键索引，NOT IN 依然不走。真正要解决，必须换查询逻辑，而不是调优参数或重建索引。
