8.2.1.13 Multi-Range Read Optimization 多个range 读优化 读记录使用一个range scan 在一个secondary index 可以导致很多的随机磁盘访问 对于基表当表是大的 不是存储在storage 引擎的cache里。 使用Disk-Sweep Multi-Range Read (MRR) 优化, MySQL 尝试降低堆积磁盘访问的数量对于range scan 通过首先只扫描索引和收集相关行的keys 然后keys 是存储和最终记录是从基表被检索使用主键的顺序。 Disk-sweep MRR是降低 随机磁盘访问的数量和完成一个更加有顺序的扫描 多范围读优化提供这些好处: 1. MRR 让数据记录被顺序的访问相比随机顺序, 基于索引元组。 server 得到一组index 元组集 满足查询条件, 排序它们更具数据记录ID顺序,使用排序的元组来按顺序的检索数据。 这个让数据访问更加有效和更便宜 MRR 启用请求的批量处理对于key 访问需要访问数据记录通过index元组, 比如range index scans和等价关联 使用索引用于关联属性。 MRR 遍历一个index range 的顺序来得到合格的index tuples. 随着那些结果的积累,它们是用于访问相应的数据记录。它是不必要获得所有的index tuples 在开始读取数据记录之前 下面的情景说明当MRR 优化可以是有利的 场景A: MRR 可以用于InnoDB 和MyISAM 表用于index range scans和等值连接操作 1. index 元组的一部分是积累在buffer里 2.元组在buffer 是按它们的数据row id排序的 3. 数据记录是通过 排序的index 元组顺序访问 方案 B:MRR 可以用于NDB 表用于多个范围index scans 或者当执行一个等值连接通过一个属性 1. ranges 的一部分, 可能简单的key 范围, 是累计在一个Buffer 在某个节点 当查询被提交时 2. range 是被发送到执行节点访问数据记录 3. 访问的记录是被打包到packages 发送会回个中心节点 4.接收到的数据是被放置到buffer里 5.数据是从Buffer 读取 当MRR 被使用,额外的列是EXPLAIN 输出显示MRR: InnoDB 和MyISAM 不使用MRR 如果full table 记录不需要被访问来产生查询结果 这种情况如果结果可以产生整个依据信息在index元组里(通过覆盖索引) MRR 不能提供任何好处 可以使用MRR的例子,假设有一个索引在(key_part1, key_part2): SELECT * FROM t WHERE key_part1 >= 1000 AND key_part1 < 2000 AND key_part2 = 10000; index 有元组组成(key_part1, key_part2) ,排序首先按key_part1 然后按key_part2 没有MRR, 一个index 扫描覆盖所有的index tuples 对于key_part1 范围从1000到2000, 不管key_part2 值在那些元组里。 scan 做额外的工作来延伸 元组在范围包含 key_part2大于1000 使用MRR, scan 是分成多个范围,每个对于一个key_part1 的单个值(1000,1001,....,1999). 每次那些扫描只需要查询元组具有 key_part2 = 10000 如果index 包含 很多元组对于 key_part2 不在10000,MRR 结果在很多少的index tuples 被读取