MySQL中!=通常不走索引，因B+树无法高效定位“非某值”的离散范围，优化器倾向全表扫描；仅当配合高选择性条件、改写为IN或使用覆盖索引时才可能利用索引。
MySQL 用 != 查询为什么走不了索引？
绝大多数情况下，!=（或 <>）会让 MySQL 放弃使用 B+ 树索引做等值定位，转为范围扫描甚至全表扫描。根本原因是：B+ 树天然适合“定位单点”或“连续区间”，而 != 的语义是“除某值外所有行”，无法转化为一个连续的索引区间——优化器一看就明白，走索引反而要回表大量数据，不如直接扫聚簇索引更省事。
常见错误现象：EXPLAIN 显示 type 是 ALL 或 index，key 为空，rows 接近表总行数；即使字段上有索引，也完全不生效。
- 只有当
!=出现在WHERE中且是唯一过滤条件时，这个问题最明显 - 如果同时有其他强过滤条件（比如带
=的高选择性列），优化器可能仍会用索引，但那是靠别的条件“带飞”，不是!=自身的功劳 -
!=对NULL无效（col != NULL永远不成立），务必用IS NOT NULL
把 != 拆成多个 = 能走索引吗？
可以，但只适用于枚举类、取值极少的字段（比如状态码、类型字段）。原理是把“排除”变成“明确包含”，让优化器能用 IN + 索引定位多个离散值。
使用场景：字段只有 'A'、'B'、'C' 三种值，你想查非 'A' 的记录。
- ❌ 错误写法：
WHERE status != 'A'→ 很可能全表扫 - ✅ 可行写法：
WHERE status IN ('B', 'C')→ 走status索引，type =range - 注意：如果字段有 20 个可能值，手写
IN20 项不仅难维护，还可能触发优化器放弃索引（MySQL 对IN列表长度敏感，通常超过几百项就降级） - 该方法对字符串、数字都适用，但对
DATETIME或大文本字段基本无意义
!= 查询必须走索引？试试覆盖索引 + SELECT * 的陷阱
即使你给查询字段加了索引，SELECT * 依然大概率让优化器放弃它——因为二级索引不包含所有列，回表成本太高，优化器宁可扫一遍聚簇索引。
性能影响很实际：一张 100 万行的表，SELECT * + != 可能比 SELECT id + != 慢 5–10 倍。
- ✅ 先确认是否真需要全部字段：如果不是，明确写出所需列，例如
SELECT id, name, status - ✅ 如果这些列都在同一个联合索引里（比如
INDEX idx_status_id_name (status, id, name)），MySQL 可能用该索引完成“覆盖扫描”，Extra显示Using index - ❌ 不要以为加了
status单列索引就够了：只要SELECT *，就一定得回主键索引取其他列，优化器大概率绕开它 - 覆盖索引对
!=的帮助是“减少 IO”，不是“让!=变快”，本质仍是范围扫描，只是不用回表
替代方案：加冗余字段 or 应用层分治
当 != 是高频核心查询，又无法改写为 IN，硬扛性能不行时，就得跳出 SQL 层想办法。
兼容性与复杂度权衡很现实：数据库层没银弹，有些问题注定得靠设计换性能。
- 加一个
is_target布尔字段，业务写入/更新时同步维护（比如status != 'archived'→is_target = 1），然后查WHERE is_target = 1，完美走索引 - 把“排除”逻辑下沉到应用层：先用
=快速查出要排除的 ID 列表（走索引），再用主键NOT IN（注意空值和 NULL 安全），适合排除集很小的场景 - 分区表可作为备选，比如按
status分区，!= 'deleted'就跳过deleted分区，但运维成本高，MySQL 8.0 前对 LIST 分区支持有限
真正容易被忽略的是：很多团队花半天调优 != 查询，却没确认这个查询是否真的必要——它是不是报表导出、后台搜索这类低频操作？如果是，加个 LIMIT 1000 或前端防抖，比索引优化见效更快。
