1.10 Multi-Range Read(MRR) Optimization(多范围读取优化)
当使用一个范围扫描在一个二级索引上查找行数据会导致许多随机的磁盘访问对于基本表的查询，如果表比较大，并且没有存储在存储引擎的缓存中的话。多范围读取的磁盘扫描优化，mysql通过首先只扫描索引来减少对范围查询中会引起的随机磁盘访问次数并且收集相关的keys集合。然后被存储的keys和通过主键顺序得到的行数据被返回。MRR磁盘扫描的动机是减少随机磁盘次数，且更加顺序的扫描基表数据。
MRR优化提供了这些好处：
>MRR能够顺序的扫描表中的行数据而不是随机的访问，通过使用索引来顺序扫描。服务器会得到一个满足查询条件的索引元组集合，根据行id顺序来排序，并且用排好序的索引数据有序的去检索数据行。这会使得数据访问更有效，而且能够减少开支。
>MRR能够批量处理请求，请求中的索引用于表中行数据的查找，比方说索引的范围扫描和在索引列上使用连接属性既equi-joins。MRR通过遍历一个索引范围序列来得到一个有用的索引集合。得到这个集合后，使用该集合获取正确的数据行集。在开始读取数据行之前，读取所有索引集合并不是必须的。
MRR的优化不能用在虚拟列上产生的二级索引上。innoDB支持在虚拟列上创建二级索引。
下面的场景说明了什么时候MRR优化是有利的。
场景A：MRR被用在了InnoDB和MyISAM表中，通过索引范围扫描查找和equi-join操作：
1) 部分索引值被存储在了缓存中。
2）在缓存中的索引值按他们数据行的ID有序存储。
3）根据有序的索引顺序来访问数据行。
场景B：MRR能够使用在NDB表中，对于多范围索引扫描或者是在一个属性上完成一个equi-join连接。
1）部分范围，可能是一个单一索引的范围，被缓存在中心节点的缓存中，当查询被提交后。
2）范围数据被发送到执行节点去查找数据行。
3）被访问的行被包装成包并且发送回中心节点。
4）接受到的包，也就是行数据，被放置在了缓存中。
5）从缓存中读取到数据行。
当MRR被使用，在EXPLAIN的Extra列中输出Using MRR.
如果查询结果不需要访问完整的表中数据来生成，那么InnoDB和MyISAM不会使用MRR.在这种情况下，查询的结果完全可以通过扫描索引数据获取，MRR不能提高效率。
下面给出一个使用了MRR的查询，假设存在一个索引在(key_part1,key_part2):
SELECT * FROM t
  WHERE key_part1 >= 1000 AND key_part1 < 2000
  AND key_part2 = 10000;
索引元组包含了(key_part1,key_part2)的值，先按key_part1排序，然后再按key_part2排序。
如果不使用MRR，一个完整的索引扫描对于key_part1范围从1000到2000，而不考虑key_part2的值在这些值中。这个扫描包含了一些其他的额外工作，其中key_part2列中的值并不是10000的行的扫描。
使用了MRR，扫描被分割为多个范围，每一个单一值的key_part1(1000,1001,...,1999)。每一个这些值的扫描只需要查看key_part2=10000的索引。如果索引中包含了许多key_part2的列值不等于10000的，那么MRR的结果可以使得少扫描许多行数据。
为了说明这个使用区间标记，non-MRR必须扫描和检查索引范围[{1000,10000},{2000,MIN_INT}],其中包含了许多除key_part2=10000意外的数据行。而MRR扫描只会查看[{1000,10000}],...,[{1999,10000}],只有key_part2=10000的行会被查询。
两个optimizer_switch 系统变量标记提供了一个是否使用MRR优化的接口。mrr变量控制了MRR是否可用。如果mrr是可用的(on),mrr_cost_based变量控制是否优化器尝试使用和不使用MRR(on)的花费开支或者是不管何时都有可能会使用(off)。默认设置，mirr是on,mrr_cost_based 也是on。具体请看8.9.3的Switchable Optimizations优化选择开关。
对于MRR,存储引擎使用变量read_rnd_buffer_size系统变量的值来确定在缓存中它能够使用的内存大小。引擎通过增加read_rnd_buffer_size的字节大小从而决定单一次缓存要处理的范围的数目。
到此关于多范围读取优化的说明就结束了。接下来我们要说明的是1.11Block Nested-Loop and Batched Key Access Joins.循环嵌套块和批量关键字访问连接。