!= 查询几乎必然触发全表扫描，因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，是成本估算下的理性退化。
用等值或范围组合替代 !=
核心思路：把“排除”逻辑，转成“明确包含”逻辑。前提是业务上能枚举或界定有效值范围。
- 若字段是状态码且取值有限（如 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'，这种语义本身可疑；真要排除某天，应确认是否需要分段查询，而非硬写不等于
警惕隐含的 != 场景
有些写法表面没出现 !=，但等价于它，同样失效：
kashen-mysql DDLtoExcel
下载
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
-
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 层。
