MySQL中!=和NOT IN多数不走索引，因B+树无法高效处理排除操作且优化器估算全表扫描更优；NOT IN还因NULL导致条件失效，应优先用NOT EXISTS替代并显式处理NULL。
MySQL 使用 NOT IN 或 != 时，绝大多数情况下不走索引，不是因为语法禁止，而是优化器主动放弃——它算出来走索引反而更慢。
为什么 != 不走索引？B+ 树根本没法高效处理“排除”
B+ 树索引的核心优势是等值查找（=）和有序范围扫描（、<code>>、BETWEEN）。但 != 表达的是“除某值外的所有行”，物理上不连续，无法定位起始+终止页；优化器必须估算：如果目标值占比小（比如 0.1%），走索引再回表可能比全表扫描还多 I/O；如果占比大（比如 99%），全表扫描一次读完更省事。最终常选 type: ALL。
常见错误现象：
-
EXPLAIN中key为空，type是ALL或index - 执行时间陡增，尤其在大表上
- 即使该列有高区分度（如主键），
id != 123也大概率不走索引
NOT IN 为什么比 != 更危险？NULL 会直接让整个条件失效
NOT IN 不仅面临和 != 相同的离散范围问题，还额外引入 NULL 语义陷阱：只要子查询结果中任意一行是 NULL，整个 NOT IN 表达式返回 UNKNOWN，最终查不到任何数据。这时优化器往往彻底放弃索引，直接全表扫。
使用场景注意点：
-
SELECT * FROM orders WHERE status NOT IN (1, 2)—— 如果status列允许 NULL，且表里真有 NULL 值，这条语句可能返回空结果，而非预期的“非 1 和 2 的所有行” - 子查询带
NULL：WHERE id NOT IN (SELECT user_id FROM logs)，只要logs.user_id有 NULL，结果恒为空 - 替代方案优先用
NOT EXISTS，它对 NULL 更鲁棒，且在某些场景下能走索引（取决于子查询写法）
什么情况下 != 或 NOT IN 反而走了索引？别依赖它
极少数情况优化器会选索引，比如：
- 表非常小（
- 该列是唯一索引（如主键或
UNIQUE约束），且统计信息准确，优化器判断!=排除的行极少 - 配合覆盖索引（
SELECT的字段全在索引里），避免回表，降低走索引的成本
但这些属于例外，不是设计依据。你不能靠“运气”写 SQL，否则上线后数据量一涨就崩。
怎么写才真正有效？把排除逻辑转成包含逻辑
核心思路：让条件回归到 B+ 树擅长的等值或连续范围。
实操建议：
-
status != 0→ 改成status > 0（如果 status 是非负整数）或status IN (1, 2, 3)（明确枚举可接受值） -
id NOT IN (1, 5, 8)→ 若值少，直接拆：id != 1 AND id != 5 AND id != 8；若值多，考虑反向思维：id >= 0 AND id <= 1000再排除（需业务允许范围限定） - 涉及 NULL 处理时，显式过滤：
status IS NOT NULL AND status != 0，避免 NULL 干扰优化器判断 - 务必用
EXPLAIN验证，尤其上线前——同一语句在不同数据分布下行为可能不同
最易被忽略的一点：复合索引下，哪怕你把 != 改成了范围，后续索引列也大概率失效。比如索引是 (a, b, c)，WHERE a = 1 AND b != 2 能用上 a，但 c 就断了。这种细节不看执行计划根本发现不了。
