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 条件按照索引建立的字段顺序来使用（最好按照顺序写，尽管优化器会进行优化）。