MySQL系列-优化之查询索引优化

这篇博客我们来谈谈如何正确使用索引以及正确建立索引，当然在开发当中情况比这个复杂多了，还要根据业务实际情况来，这篇博客就只能算是入门了，要想继续进阶的话可以和公司的DBA混个两年，前提是他愿意要带你玩。话不多说，进入正题。

如果不了解explain执行计划可以看我之前的文章MySQL系列-优化之explain执行计划详解

说明：我使用的是mysq5.5，windows10操作系统。可能实验测试结果在其他的环境下就不同了，但大抵还是一样的。未来有机会的话会写关于mysql8.0的文章，看版本更新就知道是有重大变化了，从5.7直接到8.0。

1.复合索引最左前缀匹配原则

比如说我们建立的索引是按表的a，b，c字段顺序建立的，这个时候select * from t2 where a='a' and b='b' and c='c'；这句sql语句的效率就非常高，因为我们给了三个常量，而且是全值匹配，这个是最左前缀匹配的特例，每个字段都用上了。select * from t2 where a='a' and b='b' and d='d'；这句sql使用了只使用了复合索引的字段a和字段b，因为我们复合索引不包括d这个字段。上面两个例子只体现了匹配这个原则，那么最左又是什么意思呢？比如：select * from where b='b' and c='c'; 这个sql对复合索引一个字段都用不上，只能全表扫描。为什么呢？其实你了解b+树就知道了，我们的按a，b，c的顺序建立索引，就像按a，b，c进行排序一样，如果a相同就按b排序，如果b还是相同就按c进行排序，可以比喻成三层楼，连第一层楼都没了，何来使用第二层第三层楼呢。select * from where a='a' and c='c';这句sql只能使用复合索引中的a这个字段，因为没有第二层楼也就无法使用第三层楼了。这就为什么叫最左前缀匹配原则了。

下面实测：select * from t2 where a='a' and b='b' and c='c'；ref 那一列显示了使用三个常量。

select * from t2 where a='a' and b='b' and d='d'； ref 那一列显示使用了两个常量。

select * from where b='b' and c='c'; 可以看到我们建立的索引失效了

select * from where a='a' and c='c'; ref 那一列显示使用了一个常量

2.计算函数使索引失效

直接拿例子说明，对d字段建立单值索引，d字段是字符型。

执行sql，explain select * from t2 where d='x'; ， explain select * from t2 where d>'x';

可以看到，这两条sql都用上了索引。

如果执行呢。我们用上了mysql字符长度计算函数char_length()。

可以看到，索引失效了，其实也很好理解，mysql事先只知道字符串是排好序的，但是不知道字符的具体长度，只能全表扫描了。

同样，对于sum（）和avg（）函数，mysql也只能进行全表扫描了或者索引扫描。

但是min（）和max（）就不一样了，min()/max()的结果分别返回的是B+树索引中最左边以及最右边的值，所以不需要进行表的访问就可以直接取到对应的值。当然，如果这个字段没有建立索引也就不存在使用索引这一说了。

3.范围之后索引失效

前面我们知道，对于按a，b，c建立的索引，如果a没了，bc都失效，如果b没了c会失效。那么同样，范围之后也失效。

比如select * from t2 where a='a' and b>'b' and c='c'; 这个时候我们的范围类型就是range了，查询的时候只用上了索引的a字段和b字段。实测如下：

那么对于like呢？比如说 explain select * from t2 where a='a' and b like 'b%' and c='c';

这个也很像范围，确实访问类型也是range，这个比较特殊，你可以看成 'b%' 也带点常量，只能以b开头，b字段之后的c字段并没有失效。

可以看到key_len的长度为2304，多于使用两个字段的1536。说明查询的时候使用了复合索引的三个字段。

对于select * from t2 where a='a' and b like '%b%' and c='c'; 这个就无话可说了，'%b%'无法确定范围，只能全表扫描或者索引扫描了。

4.要什么字段就拿什么字段，不要动不动就select *

虽然我前面的sql都是select *，但是在开发中千万不要这样，拿无用的字段白白损耗了数据库服务器的资源，而且数据库好不容易拿来了你又不用，你是数据库的话都会想打人了。而且本来有可能查询是覆盖索引（MySQL系列-优化之覆盖索引），被这样一弄又只能全表扫描了。

5.使用 != 的时候无法使用索引

可以看到，我们之前的sql 【select * from t2 where a='a' and b like 'b%' and c='c';】使用三个字段，现在的sql【select * from t2 where a='a' and b like 'b%' and c!='c';】只能使用索引的a和b两个字段了。

如果改成 select * from t2 where a!='a' and b like 'b%' and c='c'; 呢？

因为第一楼都崩了，所以只能全表扫描或者索引扫描了。

其实也很好理解，如果是唯一索引的话，【等于】 可以确定是某一个，范围大大缩小，而 【不等于】 只能确定不是某一个，范围和没变是一样的。

6.is null 和 is not null

这个和 = 与 != 是一样的，is null 可以大大缩小范围，而not null就不行了

可以看到 is null 使用了建立好的索引

而is not null 就不行了

7.字符串不加单引号使索引失效

执行sql select * from t2 where a='a';

可以看到使用了索引，那如果把单引号去掉呢？

执行sql select * from t2 where a=a;

索引就失效了，所以字符串一定要记得加单引号。

那如果数字类型加单引号号呢？

可以看到加不加单引号对数字类型无影响，但还是该加就加，不用加就别加。

8.in和or使用索引的问题

in和or确实是能使用索引的，而且和表的数据多少也有关系，我是mysql5.5。

可以看到，我们的t1表的n1字段上是有索引的。执行这条sql 【explain select * from t1 where n1 in('a','c');】

发现没有用上索引，因为mysql认为全表扫描效率更高，那么如果把sql修改一下呢？执行【explain select id from t1 where n1 in('a','c');】

这个时候mysql认为可以使用索引了，不光是覆盖索引，连type都变成了range，效率不错。所以不要动不动就select *。

那么我们把数据加大到30条再次执行sql【explain select * from t1 where n1 in('a','c');】

同样的sql，又用上了索引，在数据是13条的情况下没有用上，在数据变为30条的情况下用上了。

所以in里面包含常量进行查询的时候，能否使用索引和数据有很大关系。

in和or表现几乎一致，如果把常量字段增加为三个呢？

发现in和or都没用上，但是如果表的数据继续加大呢？答案是又可以用上了。这个读者可以自己玩玩。

in和or在连接常量的时候是有区别的，in会把常量排序之后存在数组当中，而or则不会，当连接的常量非常多时，in使用的二分查找（log n）比or的遍历（log n）要快。具体参考【mysql中or和in的效率问题】

9.关于 order by 和 group by

这两个都一样，因为要分组就要排序，分组是基于排序的，同样遵循最左前缀匹配原则。

 

参考教程：

谷粒学院