MySQL索引失效

一、索引失效

索引定义：索引的本质就是一种数据结构，通过某种数据结构能够快速定位获取到所需要的指定数据
索引失效：字面上其实已经解释很清楚，磁盘上文件中的数据都是一条一条的，当无法使用某种数据结构（索引）的时候，需要对文件中数据进行全部扫描才能得到所要求的的数据，因此，索引失效不是我们所希望看到的，其会严重影响查询性能

二、索引失效产生原因

原因分析：要知道索引失效产生原因，还需要从SQL语句来分析，这里就不追到MySQL底层来说，我们从执行一条SQL语句来进行分析：

// 假设在activity表上建立了name字段的普通索引
select * from activity where name = 'jan';

表数据示例.png

这条SQL在执行过程中会走索引，现在从以下几点分析：
注：索引数据结构类型有Hash和B树
索引类型有主键索引（Innodb存储引擎默认）、普通索引、联合索引、唯一索引和全文索引
其中SQL语句最后分号有否不影响

1、从查询条件分析：
（1）在建立普通索引前提下，查询条件未使用任何索引字段，此时索引失效，走全表扫描（但该情况似乎和本主题脱离，可忽略）
（2）在建立普通索引多条件前提下，若多条件下使用 or 运算，SQL语句后加 or device_id = 2，此时通过SQL执行计划可以看到该SQL未走索引

explain select * from activity where name = '234' or device_id = 2

执行语句.png

其中，type字段值为ALL，key字段值为空，说明索引失效
（3）在建立普通索引单条件前提下，SQL使用like（%开头）字句

explain select * from activity where name like '%2';

image.png

可以发现未走索引，索引失效
（4）在建立联合索引（遵循最左原则）前提下，SQL查询条件字段中未使用联合索引第一个字段

// 创建了联合索引：(name,device_id)，
//如果包含联合索引第一字段且乱序，SQL优化器会进行重排成联合索引顺序
explain select * from activity where device_id = 2;

这种情况也会索引失效
（5）查询条件对索引列运算（+、-、*、/、<>、or、in、exist）都会导致失效
（6）查询条件中索引列使用 is not null

explain select * from activity where name is not null;

（7）查询条件使用内部函数

explain select * from activity where LTRIM(name) = '234'

image.png

（8）还有一种可能因为粗心导致索引失效的情况，查询条件类型错误

explain select * from activity where name = 234

image.png

其中name字段类型为varchar，但赋值使用了数值类型