MySQL---覆盖索引和联合索引

文章目录

  • 覆盖索引
    • 思考:是否可以使用联合索引?
  • 联合索引最左前缀原则
    • 思考:建立联合索引的时候,如何定义索引内的字段顺序。
  • 索引下推
  • 联合索引失效条件

覆盖索引

create table student(
id int primary key,
name varchar(10) NOT NULL,
age int NOT NULL,
gender int NOT NULL default 1
)

对于SQLselect * from student where age between 20 and 30;,执行流程是:

  1. 先在age索引树上找到k=20的记录,取得 id;
  2. 再到id索引树查到id对应的数据;
  3. 在age索引树取下一个值age=30,取得id;
  4. 再回到ID索引树查到对应id的数据;
  5. 在age索引树取下一个值age=31,不满足条件,循环结束。

这里进行了多次的回表,因为我们知道数据存储在主键上,所以不得不回表。

为了避免这种情况,可以将SQL写成select id from student where age between 20 and 30;此时因为id的值已经在age索引树上了,因此可以直接提供查询结果,不需要回表。

像索引age已经“覆盖了”我们的查询需求,我们称为覆盖索引

覆盖索引可以减少树的搜索次数,提升查询性能,因此是一个不错的性能优化手段。

思考:是否可以使用联合索引?

联合索引又叫复合索引。是指两个或更多个列上的索引。

假如业务有一个请求,需要根据学生的名字查询他的年龄,如果请求频率较低,索引的创建会占用空间,同时利用率也没那么高,造成资源浪费。但是如果请求频率比较高,那么这个联合索引创建就有很大的意义。它可以在这个高频请求上用到覆盖索引,不再需要回表查整行记录,减少语句的执行时间。但是付出的代价就是需要维护冗余的索引,毕竟鱼和熊掌不可兼得。

联合索引最左前缀原则

当b+tree的数据项是复合的数据结构,比如联合索引index(name,age,gender),b+tree是按照从左到右的顺序来建立搜索树的,数据(瑞雯,18,0)查询的时候,b+树会优先比较name是瑞雯的来确定下一步的搜索方向,如果name相同再比较age和gender,最后得到检索的数据;但当(20,0)这样的数据没有name的时候,b+tree就不知道下一步该查哪个节点,因为建立搜索树的时候name就是第一个比较因子,必须要先根据name来搜索才能知道下一步去哪里查询。比如当(瑞雯,0)这样的数据来检索时,b+tree可以用name来指定搜索方向,但下一个字段age的缺失,所以只能把名字等于瑞雯的数据都找到,然后再匹配性别是女的数据。

思考:建立联合索引的时候,如何定义索引内的字段顺序。

我们可以根据索引的复用能力。因为支持最左前缀,所以当已经有了(name,age)这个联合索引后,一般就不需要单独在name上建立索引了。所以如果通过调整顺序,可以少维护一个索引,那么这个顺序往往就是需要优先考虑的条件。

如果没有name只有age这个条件,是无法使用联合索引的,这时候就需要创建一个单独的索引,这时候我们创建联合索引(name,age)和一个(age)的单字段索引。我们知道name的空间一般大于age的空间,这时候空间就是我们优先考虑的条件。

索引下推

当有部分不满足最左前缀原则时,MySQL引入了一种叫索引下推优化,在MySQL5.6之前,只能通过回表来获取结果。MySQL5.6之后,可以在索引遍历过程中,对索引中包含的字段先做判断,直接过滤掉不满足条件的记录,减少回表次数。

联合索引失效条件

已经知道了最左前缀原则,但是什么时候联合索引会失效呢?

首先创建一张测试表:

create table test(
a int,
b int,
c int,
d int
)

创建索引index(a,b,c,d);

1.select * from test where a = 0 and b=0 and c=0 and d=0;

此时a b c d都使用了索引。

2.select * from test where a = 0 and c=0 and b=0 and d=0;

MySQL的优化器会优化执行语句,此时和1是一样的。

3.select * from test where a = 0 and c=0 and b=0 and d>0;

MySQL的优化器会优化执行语句,此时都用到了索引。即便更换位置,也都会使用索引。

4.select * from test where a = 0 and c=0 and b>0 and d=0;

此时只有a,b用到了索引,b的范围查找">"阻塞了c,d的使用。

5.select * from test where a = 0 and c=0 and d=0;

此时只有a用到了索引,根据最左前缀原则,b没有使用,b之后的也不能使用。

6.select * from test where a = 0 and b=0 group by c, d;
此时只有a,b使用了索引,group by 查询是会先生成临时文件,再进行排序,因为字段顺序为c,d时,所以并没有用临时表进行排序,而是利用索引排序好的,order by和group by基本是一样。

有兴趣的可以在SQL前加上explain关键字通过可视化工具关注key_len来确定是否使用了索引。

总结

1.不在索引列上做任何操作(计算、函数、类型转换),会导致索引失效而转向全表扫描。
2.存储引擎不能使用索引范围条件(例如第四条SQL)右边的列。
3.查询的时候尽量索引列和查询列一致(覆盖索引),避免使用select * 进行查询。
4.mysql在使用不等于(!=或者<>)的时候会导致全表扫描无法使用索引。
5.like进行模糊查询会导致后面的列不能使用索引。
6.where 条件按照索引建立的字段顺序来使用(最好按照顺序写,尽管优化器会进行优化)。

你可能感兴趣的:(MySQL,mysql)