MySQL 用 != 或 <> 时索引真的失效了吗？
不一定失效，但绝大多数情况下无法高效使用索引进行范围扫描，只能走索引的“全索引扫描”或回表查数据，性能远不如 =、IN、BETWEEN 等操作。
根本原因是：B+ 树索引是有序结构，!= 没有明确的边界方向，优化器很难跳过某一段直接定位“不等于”的所有值；它更倾向放弃范围跳转，退化为遍历索引项 + 过滤。
- 如果字段有高选择性（比如唯一键），且查询条件能利用覆盖索引，
!=可能走index类型的执行计划（仍比ref慢） - 如果该列上有
NULL，col != 'x'不会匹配NULL行——这是常被忽略的语义陷阱，得额外写OR col IS NULL -
EXPLAIN中看到type: index或ALL，基本说明没走有效索引查找
替代 != 的三种可行写法
不是所有 != 都必须硬扛，很多业务逻辑可以拆解成等值或范围组合，让优化器重新“看懂”你的意图。
- 用
NOT IN替代单值!=—— 仅当右侧不含NULL且值数量可控（否则易触发全表扫描） - 用
<+>拆分：比如status != 2改成status < 2 OR status > 2，配合普通索引可能触发 range 访问（但要注意是否覆盖所有取值区间） - 反向思维：查出要排除的 ID 列表，再用
LEFT JOIN ... IS NULL或NOT EXISTS做反连接，适合大表排除小集合
示例：
SELECT * FROM orders WHERE user_id NOT IN (SELECT user_id FROM blacklisted);比
user_id != ...在批量排除时更可控。
哪些索引类型对 != 更友好？
普通 B+ 树索引对 != 天然不友好；但某些结构能缓解：
- 覆盖索引（
Covering Index）：如果SELECT字段全在索引中，即使走全索引扫描，也能避免回表，IO 开销下降明显 - 哈希索引（仅 Memory 引擎）：不支持范围查询，但
!=在哈希表里本质是“查一次 + 遍历其余桶”，实际并不比 B+ 树快，还牺牲排序能力，一般不推荐 - 倒排索引（8.0.27+
INVERTED索引）：适用于 JSON 数组字段的“不包含”场景，和传统!=不是一回事，别误用
结论：别指望换索引类型救 !=，优先重构查询逻辑。
!= 和统计精度、执行计划波动的关系
MySQL 优化器依赖列的统计信息估算 != 的结果集大小。一旦表数据分布突变（比如某值突然占 95%），优化器可能误判，导致本该走索引却选了全表扫描，或者反过来。
- 定期执行
ANALYZE TABLE更新统计信息，尤其在大批量INSERT/DELETE后 - 用
SHOW INDEX FROM tbl查看Cardinality是否合理，严重偏离实际唯一值数量时需干预 - 线上观察
Handler_read_next和Handler_read_rnd_next的比例，前者高说明在顺序扫索引，后者高意味着频繁回表——这是!=查询变慢的典型信号
真正麻烦的不是写法本身，而是它把优化器逼到了靠猜的地步；而猜错的成本，在高并发或大数据量下会被急剧放大。
