!=查询通常不走索引，因B+树难以高效表达“除某值外所有值”；优化应绕过语义缺陷：低基数字段改IN列表、数字/时间字段用范围条件替代、强制覆盖索引、业务层反向建模。
!= 查询在绝大多数情况下不走索引，不是因为 MySQL “不会用”，而是它发现走索引反而更慢——B+ 树没法高效表达“除了某值以外的所有值”这个离散集合。优化的关键不是强行让它走索引，而是绕过这个语义缺陷。
把 != 拆成 IN 列表（适用于低基数字段）
当字段取值非常有限（比如状态码、类型枚举），!= 'A' 可以明确改写为 IN ('B', 'C', 'D')，让优化器能用索引做多次等值查找。
- 必须确认字段实际值种类少（建议 ≤ 5–10 个），否则
IN列表过长会触发优化器降级，甚至退化为全表扫描 - 字段上要有单列索引或该字段是联合索引的最左前缀，例如
INDEX idx_status (status) - 字符串和数字都适用，但对
DATETIME、TEXT或高基数字段（如用户邮箱）无效 - 示例：
WHERE status != 'archived'→ 改为WHERE status IN ('active', 'pending', 'reviewing')
用范围条件替代 !=（仅适用于数字/时间类字段）
对可排序类型（INT、BIGINT、DATETIME），col != N 等价于 col N，MySQL 有可能利用索引做两次范围扫描。
- 需要字段有索引，且数据分布不能过于倾斜（比如 99% 的值都是
0，那0几乎等于全表扫） - 注意：如果原字段允许
NULL，col != 0不包含NULL行，而col 0也不包含，语义一致；但col != NULL永远为FALSE，必须写成col IS NOT NULL - EXPLAIN 中应看到
type = range，key非空，rows显著小于总行数 - 示例：
WHERE score != 100→WHERE score 100
强制覆盖索引 + 精确 SELECT 字段
即使无法避免 !=，只要查询只返回索引中已有的列，MySQL 就可能走“覆盖扫描”（Extra: Using index），避免回表，大幅减少 I/O。
- 必须显式写出所需字段，绝不能用
SELECT *—— 否则二级索引无法满足，优化器大概率放弃索引 - 联合索引需包含所有
SELECT字段 +WHERE中的!=字段，顺序建议把!=字段放最左（如INDEX idx_status_id_name (status, id, name)） - 覆盖扫描对大表效果极明显：100 万行表上，
SELECT id, name FROM t WHERE status != 'x'可能比SELECT *快 5 倍以上 - 验证方式：EXPLAIN 输出中
Extra字段必须含Using index，且key显示用了哪个索引
业务层预过滤或反向建模
真正难优化的 != 场景，往往暴露的是模型或逻辑问题：比如“查所有非禁用用户”本质是“查启用用户”，后者天然适合等值查询。
- 优先检查是否能把“排除逻辑”前置到写入侧：加一个
is_active布尔字段并建索引，查WHERE is_active = 1，而不是status != 'banned' - 如果查询频次高、结果集稳定，考虑物化视图或冗余字段（如
is_not_archived TINYINT），用空间换查询确定性 - 对实时性要求不高的报表类查询，可提前聚合进宽表，把
!=转为维度表上的等值关联 - 不要依赖
NOT EXISTS或子查询来“模拟”!=，它们通常更慢，且难以走索引
最易被忽略的一点：!= 和 IS NULL 是两套语义体系，col != 'x' 永远不返回 NULL 行，哪怕你加了 OR col IS NULL，也得单独处理——很多线上慢查就卡在这一步没补全。
