为什么MySQL中!=或运算符会导致B+Tree无法进行二分查找-mysql教程-PHP中文网

!= 运算符使 b+tree 索引失效，因其破坏有序性与确定搜索方向，无法界定连续区间，迫使优化器放弃二分查找而退化为全表或范围扫描。

为什么mysql中!=或<>运算符会导致b+tree无法进行二分查找

B+Tree 的查找依赖「有序性」和「确定的搜索方向」。!= 无法给出一个连续的、可跳过的大段数据区间，导致优化器放弃走索引的二分路径，转而回退到全扫描或范围扫描的低效方式。

根本原因不是语法错误，而是语义上破坏了 B+Tree 的结构优势：它没法像 = 或 那样快速定位起点 + 终点，也没法像 <code>BETWEEN 那样划定一个封闭区间。MySQL 查询优化器一看，这条路走不通，干脆不用索引了。

当 WHERE 子句中出现 OR，尤其是跨不同索引列或混合索引/非索引列时，B+Tree 的单路径查找逻辑就断了。优化器无法把多个分支条件统一映射到一棵树的一条搜索路径上。

例如 WHERE a = 1 OR b = 2，如果只有 a 有索引、b 没索引，或者 a 和 b 是两个独立的二级索引，MySQL 就不能靠一次 B+Tree 遍历拿到全部结果——它得分别查两次，再合并结果集，这个过程不走联合索引的二分逻辑。

MySQL

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

下载

只有当所有 OR 分支都命中「同一个复合索引」的最左前缀，且能推导出连续区间时，才可能走索引（例如 WHERE (a,b) = (1,2) OR (a,b) = (1,3)）
更常见的是被重写为 UNION，这时每个子查询可以单独走索引，但代价是多一次执行计划解析和结果合并
OR + NULL 判断（如 a = 1 OR a IS NULL）几乎必然导致索引失效，因为 NULL 不参与 B+Tree 排序比较

不是所有 != 或 OR 都必须硬扛全表扫描。关键看能不能把语义转换成 B+Tree 友好的区间操作或覆盖路径。

用 NOT IN 替代 != 并不解决问题，反而更糟（含 NULL 时结果不可控，且同样无法利用索引）
把 WHERE status != 'done' 改成 WHERE status IN ('pending', 'processing', 'failed')，前提是枚举值稳定且数量可控——这样每个值都能走等值查找
对 OR，优先考虑改写为 UNION ALL，并确保每个分支都有对应索引支撑，例如：
```
SELECT * FROM t WHERE a = 1
UNION ALL
SELECT * FROM t WHERE b = 2 AND a IS NULL;
```
复合索引设计上预留组合空间，比如把常一起 OR 的字段建为 (a,b)，再配合 IN 或范围条件使用