MySQL 5.6开始支持Multi-Range Read(MRR)优化。目的是味儿减少磁盘的随机访问，并且将随机访问转化为较为顺序的数据访问，这对IO-bound类型的SQL查询语句可带来性能极大的提升。MRR优化可适用于rangeref,eq_ref类型的查询
MRR优化的好处
a)MRR使数据访问变得较为顺序。在查询辅助索引时，首先根据得到的查询结果按照主键进行排序，并按照主键排序的顺序进行书签查找
b)减少缓冲池中页被替换的次数
c)批量处理对键值的查询操作
对于InnoDB和MyISAM存储引擎的范围查询和JOIN查询操作，MRR工作方式如下
a)将查询得到的辅助索引键值存放在一个缓存中，这是缓存中的数据是根据辅助索引键值排序的
b)将缓存中的键值根据RowID进行排序
c)根据RowID的排序顺序来访问实际的数据文件
此外，若InnoDB存储引擎或者MyISAM存储引擎的缓冲池不足够大，即不能存放下一张表中的所有数据，此时频繁的离散读操作还会导致缓存中的页被替换出缓冲池，然后有不断地被读入缓冲池。若按照主键顺序访问，则可以将重复行为降为最低，如
SELECT * FROM salaries WHERE salary>10000 and salary<40000;
salary有一个辅助索引idx_s，因此除了通过辅助索引查找键值外，还需要通过书签来进行对整行数据的查询，当不启用MRR特性，执行计划如下
若启用MRR
在实际执行中，两者的执行时间差非常大
此外，MRR还可以将某些范围查询，拆分为键值对，以此来进行批量的数据查询，这样的好处是可以在拆分过程中，直接过滤一些不符合查询条件的数据，如
SELECT * FROM t WHERE key_part1>=1000 and key_part1<2000 AND key_part2=1000;
表t有(key_part1,key_part2)的联合索引因此索引根据key_part1,key_part2的位置关系进行排序。若没有MRR，此时查询类型为Range。SQL优化器会先将key_part1>1000 and key_part2<2000的数据线取出来，即使key_part2不等于1000。待取出的行数据后在根据key_part2的条件进行过滤，这会导致无用的数据被取出，如果有大量的数据且其key_part2不等于1000，则启用MRR优化会使性能有巨大的提升
启用MRR优化，优化器会先将查询条件进行拆分，然后在进行数据查询。上述语句，优化器会将查询条件拆分为(1000,1000),(1001,1000),(1002,1000),...,(1999,1000)，然后在根据这些拆分出的条件进行数据查询
SELECT * FROM salaries WHERE(from_date between ‘‘1986-01-01‘ AND ‘1995-01-01‘) AND(salary between 38000 and 40000);
若启用MRR优化，执行计划为
表salaries上对于salary的索引idx_s，在执行SQL中，启用了MRR优化，所以会对查询条件进行拆分，故此可以看到Using MRR
是否启用MRR优化可以通过optimizer_switch中的标记(flag)来控制，当mrr为ON时，启用.mrr_cost_based标记为是否通过cost based方式来选择是否启用mrr.若mrr设为on，mrr_cost_based设为off,则总是启用MRR优化。
set @@optimizer_switch=‘mrr=on,mrr_cost_based=off‘;
参数read_rnd_buffer_size用来控制键值的缓冲区大小,当大于该值，执行器对已经缓存的数据根据RowID进行排序，并通过RowID来取得行数据。该值默认为256K