索引失效的10种场景

1、不满足最左匹配原则

例：

给sex、age和name这3个字段建好联合索引：id_sex_age_name

该索引字段的顺序是：

1、sex

2、age

3、name

再看看哪些情况下，能走索引：

explain select * from 某表
where sex='男';

explain select * from 某表
where sex='男' and age=21

explain select * from 某表
where sex='男' and age=21 and name='周星驰';

执行结果：上面三种情况，sql都能正常走索引

其实还有一种比较特殊的场景：

explain select * from 某表
where sex= '男'  and name='周星驰';

执行结果：查询条件原本的顺序是：sex、age、name，但这里只有sex和name中间断层了，掉了age字段，这种情况也能走sex字段上的索引

规律：

这4条sql中都有sex字段，它是索引字段中的第一个字段，也就是最左边的字段。只要有这个字段在，该sql已经就能走索引

这就是我们所说的最左匹配原则

2、索引列上有计算

根据id查询数据的sql语句：

explain select * from 某表 where id=1;

执行结果：

从图中可以看出，由于id字段是主键，该sql语句用到了主键索引

但如果id列上面有计算，比如：

explain select * from 某表 where id+1=2;

执行结果：

从上图中的执行结果，能够非常清楚的看出，该id字段的主键索引，在有计算的情况下失效了 

3、索引列用了函数

假如现在有个需求，想查出所有身高是17开头的人，如果sql语句写成这样：

explain select * from 某表 where height=17;

执行结果：

该sql语句确实用到了普通索引

但该sql语句肯定是有问题的，因为它只能查出身高正好等于17的，但对于174这种情况，它没办法查出来

为了满足上面的要求，我们需要把sql语句稍稍改造了一下：

​explain select * from 某表 where SUBSTR(height,1,2)=17;

这时需要用到SUBSTR函数，用它截取了height字段的前面两位字符，从第一个字符开始

执行结果：

在使用该函数之后，该sql语句竟然走了全表扫描，索引失效了 

4、字段类型不同

请大家注意观察一下此表中的code字段，它是varchar字符类型的

在sql语句中查询数据时，查询条件我们可以写成这样：

explain 
select * from 某表 where code="101";

执行结果：

从上图中看到，该code字段走了索引

温馨提醒一下，查询字符字段时，用双引号“和单引号'都可以

但如果你在写sql时，不小心把引号弄掉了，把sql语句变成了： 

explain 
select * from 某表 where code=101;

执行结果：

你会惊奇的发现，该sql语句竟然变成了全表扫描。code字段上的索引也失效了 

那么为什么索引会失效呢：

因为code字段的类型是varchar，而传参的类型是int，两种类型不同

此外，还有一个有趣的现象，如果int类型的height字段，在查询时加了引号条件，却还可以走索引：

explain select * from 某表
where height='175';

执行结果：

从图中看出该sql语句确实走了索引。int类型的参数，不管在查询时加没加引号，都能走索引

这是为什么呢： 

因为mysql发现如果是int类型字段作为查询条件时，它会自动将该字段的传参进行隐式转换，把字符串转换成int类型。mysql会把上面列子中的字符串175，转换成数字175，所以仍然能走索引

接下来，看一个更有趣的sql语句：

select 1 + '1';

它的执行结果是2，还是11:

结果是2

mysql自动把字符串1，转换成了int类型的1，然后变成了：1+1=2

但如果你确实想拼接字符串该怎么办：

可以使用concat关键字

select concat(1,'1');

关键问题来了：为什么字符串类型的字段，传入了int类型的参数时索引会失效呢：

根据mysql官网上解释，字符串1、数字1、字符串1a都能转换成int类型的1，也就是说可能会出现多个字符串，对应一个int类型参数的情况

那么，mysql怎么知道该把int类型的1转换成哪种字符串，用哪个索引快速查值：

感兴趣的小伙伴可以再看看官方文档：https://dev.mysql.com/doc/refman/8.0/en/type-conversion.html

5、使用了select *

在《阿里巴巴开发手册》中明确说过，查询sql中禁止使用select * 。

例：

explain 
select * from 某表 where name='苏三';

执行结果：

在该sql中用了select *，从执行结果看，走了全表扫描，没有用到任何索引，查询效率是非常低的 

如果查询的时候，只查我们真正需要的列，而不查所有列，结果会怎么样：

explain 
select code,name from 某表
where name='苏三';

执行结果：

从图中执行结果不难看出，该sql语句这次走了全索引扫描，比全表扫描效率更高

其实这里用到了：

覆盖索引

如果select语句中的查询列，都是索引列，那么这些列被称为覆盖索引。这种情况下，查询的相关字段都能走索引，索引查询效率相对来说更高一些

而使用select *查询所有列的数据，大概率会查询非索引列的数据，非索引列不会走索引，查询效率非常低

6、like左边包含%

目前like查询主要有三种情况：

1、like '%a'

2、like 'a%'

3、like '%a%'

假如现在有个需求，想查出所有code是10开头的用户：

explain select * from 某表
where code like '10%';

执行结果：

如果把需求改了，想出现所有code是1结尾的用户：

explain select * from 某表
where code like '%1';

执行结果：

从图中看出这种%在1左边时，code字段上索引失效了，该sql变成了全表扫描 

此外，如果出现以下sql：

explain select * from 某表
where code like '%1%';

该sql语句的索引也会失效

下面用一句话总结一下规律：

当like语句中的%，出现在查询条件的左边时，索引会失效

7、列对比

假如我们现在有这样一个需求，过滤出表中某两列值相同的记录。比如user表中id字段和height字段，查询出这两个字段中值相同的记录：

explain select * from user 
where id=height

执行结果：

 id字段本身是有主键索引的，同时height字段也建了普通索引的，并且两个字段都是int类型，类型是一样的

但如果把两个单独建了索引的列，用来做列对比时索引就会失效

8、使用or关键字

某天你遇到这样一个需求，想查一下user表id=1或者height=175的用户：

explain select * from user 
where id=1 or height='175';

执行结果：

这次确实走了索引，因为刚好id和height字段都建了索引 

但接下来需求改了，除了前面的查询条件之后，还想加一个address='成都'：

explain select * from user 
where id=1 or height='175' or address='成都';

执行结果：

结果之前的索引都失效了

为什么呢：

因为你最后加的address字段没有加索引，从而导致其他字段的索引都失效了

注意：

如果使用了or关键字，那么它前面和后面的字段都要加索引，不然所有的索引都会失效，这是一个大坑

9、not in和not exists

在我们日常工作中用得也比较多的，还有范围查询，常见的有：

1、in

2、exists

3、not in

4、not exists

5、between and

今天重点聊聊前面四种

9.1、in关键字

假如我们想查出user表中height在某些范围之内的用户，这时sql语句可以这样写：

explain select * from user
where height in (173,174,175,176);

执行结果：

从图中可以看出，sql语句中用in关键字是走了索引的 

9.2、exists关键字

有时候使用in关键字时性能不好，这时就能用exists关键字优化sql了，该关键字能达到in关键字相同的效果：

explain select * from user  t1
where  exists (select 1 from user t2 where t2.height=173 and t1.id=t2.id)

执行结果：

从图中可以看出，用exists关键字同样走了索引 

9.3、not in关键字

再先看看使用not in的情况：

explain select * from user
where height not in (173,174,175,176);

执行结果：

没错，索引失效了 

看如果现在需求改了，想查一下id不等于1、2、3的用户有哪些，这时sql语句可以改成这样：、

explain select * from user
where id  not in (1，2，3);

执行结果：

你可能会惊奇的发现，主键字段中使用not in关键字查询数据范围，任然可以走索引。而普通索引字段使用了not in关键字查询数据范围，索引会失效 

9.4、not exists关键字

除此之外，如果sql语句中使用not exists时，索引也会失效。具体sql语句如下：

explain select * from user  t1
where  not exists (select 1 from user t2 where t2.height=173 and t1.id=t2.id)

执行结果：

从图中看出sql语句中使用not exists关键后，t1表走了全表扫描，并没有走索引

10、order by的坑

假如user表code、age和name这3个字段上，已经建了联合索引：idx_code_age_name

10.1、哪些情况走索引？

10.1.1、满足最左匹配原则

order by后面的条件，也要遵循联合索引的最左匹配原则。具体有以下sql：

explain select * from user
order by code limit 100;
 
explain select * from user
order by code,age limit 100;
 
explain select * from user
order by code,age,name limit 100;

执行结果：

从图中看出这3条sql都能够正常走索引 

10.1.2、配合where一起使用

order by还能配合where一起遵循最左匹配原则：

explain select * from user
where code='101'
order by age;

执行结果：

假如中间断层了，sql语句变成这样，执行结果会是什么呢：

explain select * from user
where code='101'
order by name;

执行结果：

 很明显上图2条sql都能够正常走索引

10.1.3、相同的排序

order by后面如果包含了联合索引的多个排序字段，只要它们的排序规律是相同的（要么同时升序，要么同时降序），也可以走索引。具体sql如下：

explain select * from user
order by code desc,age desc limit 100;

执行结果：

该示例中order by后面的code和age字段都用了降序，所以依然走了索引

10.1.4、两者都有

如果某个联合索引字段，在where和order by中都有，结果会怎么样：

explain select * from user
where code='101'
order by code, name;

 执行结果：

code字段在where和order by中都有，对于这种情况，从图中的结果看出，还是能走了索引的 

10.2、哪些情况不走索引？

10.2.1、没加where或limit

如果order by语句中没有加where或limit关键字，该sql语句将不会走索引：

explain select * from user
order by code, name;

执行结果：

从图中看出索引真的失效了

10.2.2、对不同的索引做order by

前面介绍的基本都是联合索引，这一个索引的情况。但如果对多个索引进行order by，结果会怎么样呢：

explain select * from user
order by code, height limit 100;

执行结果：

 从图中看出索引也失效了

10.2.3、不满足最左匹配原则

前面已经介绍过，order by如果满足最左匹配原则，还是会走索引。下面看看，不满足最左匹配原则的情况：

explain select * from user
order by name limit 100;

执行结果：

name字段是联合索引的第三个字段，从图中看出如果order by不满足最左匹配原则，确实不会走索引

10.2.4、不同的排序

前面已经介绍过，如果order by后面有一个联合索引的多个字段，它们具有相同排序规则，那么会走索引，但如果它们有不同的排序规则呢：

explain select * from user
order by code asc,age desc limit 100;

执行结果：

从图中看出，尽管order by后面的code和age字段遵循了最左匹配原则，但由于一个字段是用的升序，另一个字段用的降序，最终会导致索引失效