!= 操作符几乎不走b+树索引，因其无法表达为连续区间，优化器倾向全表扫描；仅当与高选择性条件共用、覆盖索引或改写为in/范围查询时才可能走索引。
!= 为什么几乎不走索引
B+ 树索引天生不适合处理 != 这类语义：它擅长快速定位“某个值”或“一段连续范围”，但 != 'A' 表示“除 A 外所有值”，在索引结构里无法表达为一个或多个连续区间——优化器一看就知道，走索引要反复跳转、回表大量行，还不如直接扫聚簇索引一次到位。
典型表现：EXPLAIN 中 type 是 ALL 或 index，key 为空，rows 接近表总行数。哪怕 status 字段上有单列索引，WHERE status != 'done' 也大概率被无视。
哪些情况可能“意外”走索引
不是 != 变聪明了，而是其他条件“带飞”了它：
- 当
!=和高选择性等值条件共存时，比如WHERE status != 'archived' AND create_time > '2025-01-01'，优化器可能用create_time索引先筛出少量数据，再在结果集里过滤status - 覆盖索引下，
SELECT id, status FROM orders WHERE status != 'completed'若有联合索引INDEX idx_status_id (status, id)，可能走该索引并显示Using index——但这只是避免回表，扫描量没变小 -
IS NOT NULL虽然语法上像“不等于”，但它能走索引（IS NULL也能），而col != NULL永远为 false，千万别混用
真想让 != 查询快一点，怎么办
核心思路是把“排除”改成“明确列举”或“拆成范围”：
- 字段取值极少（如状态码只有
'pending'、'processing'、'done'）：改写为WHERE status IN ('pending', 'processing')，能走status索引，type = range - 数值型主键或时间字段：用
WHERE id 2000替代id != 1500，前提是业务逻辑允许且范围可控 - 务必避免
SELECT *：即使加了覆盖索引，*也会迫使优化器放弃索引；只查需要的列，并确保它们包含在联合索引最左前缀中 - 别硬凑长
IN列表：超过几百项，MySQL 可能直接降级为全表扫描；字段值多于 5–6 个时，就得重新评估是否该调整业务逻辑或建模方式
容易被忽略的陷阱
很多人试过 IN 改写后发现还是慢，问题常出在细节：
-
status列上有索引，但IN里写了'pending '（带空格）或大小写不一致，导致隐式类型转换，索引失效 - 联合索引是
(tenant_id, status)，但查询只用了status != 'x'，没带上tenant_id = ?，最左前缀断了，索引压根不参与 - 字段允许
NULL，但IN列表没包含NULL，而业务上需要返回这些记录——IN不会匹配NULL，得额外补OR status IS NULL
真正关键的从来不是“怎么写 !=”，而是“这个查询是否必须用 !=”——多数时候，换一种业务表达方式，比在 SQL 层硬扛更有效。
