Mysql 索引失效场景

**1 联合索引不满足最左匹配原则 **

在联合索引中，最左侧的字段优先匹配。因此，在创建联合索引时，where子句中使用最频繁的字段放在组合索引的最左侧。

而在查询时，要想让查询条件走索引，则需满足：最左边的字段要出现在查询条件中。

** 2使用了select ***

【强制】在表查询中，一律不要使用 * 作为查询的字段列表，需要哪些字段必须明确写明。 
说明:1)增加查询分析器解析成本。2)
增减字段容易与 resultMap 配置不一致。3)
无用字段增加网络 消耗，尤其是 text 类型的字段。

3 索引列参与运算

即便id列有索引，由于进行了计算处理，导致无法正常走索引。

针对这种情况，其实不单单是索引的问题，还会增加数据库的计算负担。

4 索引列参使用了函数

索引列使用了函数（SUBSTR，字符串截取），导致索引失效。

此时，索引失效的原因与第三种情况一样，都是因为数据库要先进行全表扫描，获得数据之后再进行截取、计算，导致索引索引失效。同时，还伴随着性能问题。

5 错误的Like使用

方式一：like ‘%abc’；
方式二：like ‘abc%’；
方式三：like ‘%abc%’；
其中方式一和方式三，由于占位符出现在首部，导致无法走索引。这种情况不做索引的原因很容易理解，索引本身就相当于目录，从左到右逐个排序。而条件的左侧使用了占位符，导致无法按照正常的目录进行匹配，导致索引失效就很正常了。

第五种索引失效情况：模糊查询时（like语句），模糊匹配的占位符位于条件的首部。

6 类型隐式转换

参数类型与字段类型不匹配，导致类型发生了隐式转换，索引失效

7、使用OR操作

查询条件使用or关键字，其中一个字段没有创建索引，则会导致整个查询语句索引失效； or两边为“>”和“<”范围查询时，索引失效。

8 两列做比较

如果两个列数据都有索引，但在查询条件中对两列数据进行了对比操作，则会导致索引失效。

这里举个不恰当的示例，比如age小于id这样的两列（真实场景可能是两列同维度的数据比较，这里迁就现有表结构）：

9 不等于比较

当查询条件为字符串时，使用”<>“或”!=“作为条件查询，有可能不走索引，但也不全是。

10 is not null

查询条件使用is null时正常走索引，使用is not null时，不走索引。

11 not in和not exists

查询条件使用not in时，如果是主键则走索引，如果是普通索引，则索引失效。

12 order by导致索引失效

主键使用order by索引有效
：当查询条件涉及到order by、limit等条件时，是否走索引情况比较复杂，而且与Mysql版本有关，通常普通索引，如果未使用limit，则不会走索引。order by多个索引字段时，可能不会走索引。其他情况，建议在使用时进行expain验证

13 参数不同导致索引失效

当查询条件为大于等于、in等范围查询时，根据查询结果占全表数据比例的不同，优化器有可能会放弃索引，进行全表扫描。