8.2.1.13 Multi-Range Read Optimization 多个range 读优化

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 被读取