覆盖索引的优化点和注意点

金三银九，虽然收到了疫情的冲击。但对于即将踏入社会的我们来说很重要的一段时间。在最近准备面试的过程当中发现，其实对于业务系统来说。Mysql的线上性能调优经验又是非常被看重的一件事情。那么结合我在研究生期间的工作和实习经历来说，对于Mysql的线上调优工作做了一下几个方面的总结，希望能够帮助到所有有需要的同学。在这个不一样的烟花三月当中，一起加油。
关于Mysql调优，可能大的思路我们可以主要分为以下几个部分：索引，性能抖动，长事务带来的影响，大表的连接查询优化这几个方面，今天就来分享以下一些日常生活当中积累的一些思路和原理。

索引

说起索引，我们首先想到的就是添加索引能够加快我们的查询，提高服务的能力。但是在索引调优过程中，我们又需要着重注意以下几个方面的问题：1.创建什么类型的索引？2.如果发现优化器没有选择指定的索引，该如何优化？

创建索引

覆盖索引

优点一：避免回表

覆盖索引的含义是索引项上包含了查询的全部内容。我们知道，在创建一个普通的二级索引的时候，底层的索引节点上只包含了索引字段和id，如果需要其他的数据，我们就需要根据id进行回表操作。这可能就会带来额外的磁盘IO开销。而如果使用覆盖索引，我们可以有效的避免回表操作。初次之外，Mysql5.6之后对覆盖索引进行了进一步的优化，即推出了索引下推功能，支持覆盖索引在必要的回表操作之前根据已有字段进行进一步的筛选，从而减少回表的次数。

再进一步，如果我们的线上数据库的底层使用的是机械硬盘（机械硬盘的数据读取需要进行磁盘的转动和扇区的寻找，因此随机读写的开销非常大），我们就需要考虑进一步的优化回表时的随机读写。针对这个问题，Mysql也给出了相应的解决办法，即支持MRR（Multi-Range-Read)。MRR可以将回表操作全部暂存在一块叫做read_rnd_buffer当中，然后进行排序，将有序的Id进行回表操作。这样做的好处有两个：（1）批处理操作能够提高效率。（2）能够将随机读写转换为顺序读写进行优化。这对线上业务是机械硬盘的Mysql更为友好。

优点二：避免排序

而覆盖索引除了可以减少回表的次数之外，还可以避免排序。我们知道InnoDB是基于索引组织结构的，并且底层使用B+树作为其存储的数据类型【注1】。因此InnoDB表中的数据在插入时就是有序的。因此当我们的业务中需要排序的字段上有索引时就可以避免排序操作。而如果没有索引，InnoDB引擎则会通过全字段排序，rowid排序，或者Mysql5.6之后引入的优先队列排序算法进行排序之后返回，在这个过程当中不仅会占用cpu资源，还有可能用到临时文件，因此应该在业务当中尽量避免。

优点三：减少维护的索引

我们知道，在InnoDB当中的每一个索引都对应着一棵索引树，并在磁盘当中对应着一个索引文件。而当表中业务量大而线上磁盘容量有限的时候，如果可以少维护一个索引却能够达到相同的效果，所带来的优化也是不容忽视的。那就需要我们在设计覆盖索引时满足最左原则【注】通过合理的安排覆盖索引的位置，我们可以少维护索引。例如 index2(a,b)，我们就可以不再单独维护索引a。