!= 查询几乎必然触发全表扫描，因B+树无法高效定位“不等于”值，优化器基于成本估算主动放弃索引；应改用IN、范围组合或默认值替代，并通过EXPLAIN验证key非空、type非ALL。

!= 和 在 MySQL 中几乎必然触发全表扫描，这不是配置问题，也不是索引没建好——而是优化器明确放弃走索引。因为 B+ 树索引本质是有序结构，它能高效定位“等于”“范围”“前缀匹配”，但无法高效回答“哪些不等于某值”。哪怕字段上有索引，只要 WHERE 里出现 !=，key 字段在 EXPLAIN 中基本为 NULL，type 为 ALL。

为什么 != 一定走全表扫描

MySQL 的索引不存储“缺失值”的位置信息。比如索引列有值 1、2、3、4、5，WHERE id != 3 需要返回其余全部 4 行，优化器发现：扫一遍表可能比反复回表查索引再过滤还快。尤其当不等于的值占比高（如 > 10%），优化器会直接判定“全表扫更省事”。这不是 bug，是成本估算下的理性退化。

用等值或范围组合替代 !=

核心思路：把“排除”逻辑，转成“明确包含”逻辑。前提是业务上能枚举或界定有效值范围。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

• 若字段是状态码且取值有限（如 status ∈ {0,1,2,3}），把 WHERE status != 0 改成 WHERE status IN (1, 2, 3)
• 若字段是数字类型且有自然边界，WHERE price != 100 可拆为 WHERE price 100（注意：这仍可能因 OR 导致索引失效，需确保 price 有单列索引）
• 字符串非空判断别用 name != ''，改用 name > ''（MySQL 中空字符串比任何非空字符串小）
• 时间字段避免 create_time != '2024-01-01'，这种语义本身可疑；真要排除某天，应确认是否需要分段查询，而非硬写不等于

警惕隐含的 != 场景

有些写法表面没出现 !=，但等价于它，同样失效：

• IS NULL 和 IS NOT NULL：B+ 树默认不存 NULL，所以 WHERE col IS NOT NULL 无法利用索引。解法是设默认值（如 0 或 ' '），改查 col != 0 → 实际还是得转成 col > 0 或 col IN (...)
• NOT IN (a, b, c)：右侧含 NULL 时整个条件恒为 FALSE；即使不含 NULL，也大概率全表扫。优先用 NOT EXISTS 或反向 LEFT JOIN ... WHERE xxx IS NULL
• WHERE a NOT LIKE 'xxx%'：这不是“排除前缀”，而是模糊否定，无法走索引，慎用

验证是否真绕过了全表扫描

别依赖猜测，每次改完必须跑 EXPLAIN 看执行计划：

• 检查 key 字段是否非 NULL（用了哪个索引）
• 确认 type 不是 ALL（至少是 range、ref 或 const）
• 留意 Extra 是否出现 Using where（表示索引下推生效），而不是仅 Using where（表示存储引擎返回后由 server 层过滤）
• 如果用了 UNION ALL 拆 OR，要分别 EXPLAIN 每个子句，确保各自走了索引

真正难的不是写出替代写法，而是判断业务逻辑是否允许这么改——比如状态字段是否真的只有几个确定值、NULL 是否可被默认值替代、数据分布是否让 IN 列表足够紧凑。这些决定往往卡在需求层，而非 SQL 层。