上篇文章末尾我们提出一个问题：有没有什么办法可以尽量避免回表或让回表的开销变小呢？
本篇文章围绕这个问题提出解决方案，一起来看看MySQL是如何优化的
回表
为什么会发生回表？
因为使用的索引并没有整条记录的所有信息，因此使用索引后不满足查询列表需要的列，就要回表查询聚簇索引
回表查询聚簇索引时，由于主键值是乱序的这样就会导致随机IO
什么是随机IO呢？
MySQL查询时，需要将磁盘的数据加载到缓冲池中，与磁盘交互的单位是页，页中存在多条记录
由于获取的是聚簇索引的页，那么该页中的主键值是有序的，但在二级索引上的记录主键值可能并不是有序的
比如图中第一条记录主键值为24记录在页A中，第二条记录主键值为82546记录在页C中
当遍历到第一条记录时需要去加载页A，当遍历下一条记录时需要去加载页C
当这种随机IO过多时，可能每查一条记录相当于要去加载一个页，成本非常大
不要小瞧回表的开销，当查询数据量大，使用二级索引都要回表的话，性能还不如全表扫描（扫描聚簇索引），这通常也是索引失效的一大场景（后续文章再来聊聊这块）
Multi Range Read 多范围读取
那有没有什么办法降低成本呢？
回表成本大的原因主要是产生随机IO，那能不能先在索引上查出多条记录，要回表时对主键值进行排序，让随机IO变成顺序IO呢
对主键值排序后每个加载的页，页中可能存在多条需要回表查询的记录就减少回表随机IO的开销
MySQL中另一个优化回表的手段是：Multi Range Read 多范围读取 MRR
MRR使用缓冲区对需要回表的记录根据主键值进行排序，将随机IO优化为顺序IO
使用MRR优化后图中第二条记录id为25回表时就可以直接在缓冲池的页A中获取完整记录
查看MRR缓冲池大小show variables like '%read_rnd_buffer_size%';
可以使用查看相关优化器的参数SHOW VARIABLES LIKE 'optimizer_switch';
有关MRR的优化器开关参数：mrr，mrr_cost_based
mrr 表示是否开启MRR
MRR还需要在缓冲池中排序的开销，因此并不是所有场景都用MRR，默认情况下启动mrr_cost_based基于成本判断是否要使用MRR
SET optimizer_switch='mrr=on,mrr_cost_based=off';关闭根据成本判断是否用MRR
附加信息携带Using MRR说明使用MRR
除了将随机IO优化为顺序IO，还有没有什么方式可以降低回表的开销呢？
我们从另一个角度分析，如果减少查询的数据量，是不是也可以减少回表次数，降低回表开销
那如何减少数据量呢？实际上上篇文章说过的ICP就可以减低回表次数
Covering Index 覆盖索引
回表无论如何优化都会存在一定的开销，那有没有可能避免回表呢？
要避免回表问题，那就要知道为什么会回表？
由于使用的二级索引不包含查询需要的字段，因此需要回表查询聚簇索引获取需要的字段
那如果使用的二级索引包含需要的查询字段是不是就避免回表的呢！
因此可以通过修改查询需要的字段select xx1,xx2或 增加二级索引包含的列（变成联合索引）来避免出现回表
注意：如果你想通过增加二级索引的列来避免回表时，需要评估二级索引存在列太多的维护成本
MySQL中的覆盖索引指的是使用二级索引时不需要回表，在执行计划中的附加信息显示Using index
将查询列表从 * 改为 age,student_name ,使用二级索引时不需要回表
总结
当使用的二级索引不满足查询需要的列时，会进行回表查询聚簇索引获取完整记录
回表不仅需要再查一次聚簇索引，而且在二级索引中主键值可能是乱序的，因此查询聚簇索引会出现随机IO
查询随机IO时可能每条记录都在不同的页中，这会导致每查询一条记录就需要将磁盘中的页加载到缓冲池，随机IO开销很大
优化回表有两种思路：一种是降低回表的开销，另一种是避免回表
Index Condition Push 索引条件下推（上篇文章说的）可以减少回表次数，降低回表的开销
Multi Range Read 多范围读取在某些场景下使用缓冲池排序主机，将读取的随机IO转换为顺序IO，降低回表开销
修改查询需要的字段或者给二级索引上增加列，使用覆盖索引的方式来避免回表
