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

原文地址:https://www.cnblogs.com/zhaoyangjian724/p/6199134.html