Multi-Range Read优化

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Multi-Range Read优化相关的知识,希望对你有一定的参考价值。

参考技术A mysql Multi-Range Read(MRR)优化主要用于在使用二级索引访问数据时减少随机读。

本文主要翻译自 MySQL官方文档对MRR的介绍 。

当表的数据非常多以至于无法放入缓存时,基于二级索引的范围扫描读取数据会造成较多的硬盘随机读。如果启用了MRR优化,MySQL首先会基于索引进行数据定位并收集满足条件的keys,然后再对这些keys进行排序,这样可以以主键的顺序进行表行的读取,能够减少随机读的数量。MRR优化的目的就是通过对keys排序后的一定程度的顺序读减少随机读的数量。

MRR的优点如下:

下面列出的场景能够证明MRR优化的优点:

场景A,在 InnoDB 和 MyISAM 基于索引范围访问和 equi-join 操作时,MRR优化可以发挥作用:

场景B,MRR可以在 NDB 基于 multiple-range index 扫描和 equi-join 是发挥作用:

使用MRR时, EXPLAIN 输出的 Extra 列会显示 Using MRR 。

当不需要进行全表访问时(full table), InnoDB 和 MyISAM 不会进行MRR优化,因为如果查询结果可以基于索引得出(比如覆盖索引),那么使用MRR将没有意义。

系统变量 optimizer_switch 使用标识 mrr 控制是否启用MRR优化,如果配置启用MRR优化,标识 mrr_cost_based 用来决定是否基于代价来决定是否进行MRR优化。默认情况下,MRR为启用状态,并且 mrr_cost_based 也是启用状态。

启用MRR优化时, read_rnd_buffer_size 用于控制分配多大空间积累批量访问表行数据的索引数据。

浅析MySQL中的Index Condition Pushdown (ICP 索引条件下推)和Multi-Range Read(MRR 索引多范围查找)查询优化

 

本文出处:http://www.cnblogs.com/wy123/p/7374078.html
(保留出处并非什么原创作品权利,本人拙作还远远达不到,仅仅是为了链接到原文,因为后续对可能存在的一些错误进行修正或补充,无他)

 

 

ICP优化原理

Index Condition Pushdown (ICP),也称为索引条件下推,体现在执行计划的上是会出现Using index condition(Extra列,当然Extra列的信息太多了,只能做简单分析)
ICP原理通俗讲就是,查询过程中,直接在查询引擎层的API获取数据的时候实现"非直接索引"过滤条件的筛选,而不是查询引擎层查询出来之后在Server层筛选。
换句话说就是ICP在获取数据的同时实现了where的次选条件中无法直接使用索引的情况下的筛选,避免了没有ICP优化的时候分两个步骤的实现(获取数据的过程没有做次选条件的过滤)
如果是非ICP优化查询的话,是两步,第一步是获取数据,第二步是获取的数据进行条件筛选。
显然,相比后者,前者可以一步实现索引的查找Seek+filter,效率上更高。

适应的场景:
ICP的优化策略可用于range、ref、eq_ref、ref_or_null 类型的访问数据方法

其实没有实例不太好理解这种优化策略,还是举两个实际列子吧。

 

ICP优化实例

第一个例子在网上非常多,也非常容易理解.具体表结构见上文(http://www.cnblogs.com/wy123/p/7366486.html

下面用到的test_orderdetail表的索引为:create index idx_orderid_productname on test_orderdetail(order_id,product_name);
查询语句为:select * from test_orderdetail where order_id = 10900 and product_name like \'%00163e0496af%\';
显然,order_id = 10900是可以直接进行索引查找的,虽然product_name也包含在复合索引中,但是product_name like \'%00163e0496af%\'是无法使用索引的
观察其执行计划,发现Extra中是Using index condition。

ICP在这里的优化原理就是,
在利用第一个条件 order_id = 10900 进行索引查找的过程中,同时使用product_name like \'%00163e0496af%\'这个无法直接使用索引查找的条件进行过滤。
最终一步就可以筛选出来结果。

set optimizer_switch=\'index_condition_pushdown=off或者on\'

  对比关闭ICP优化的情况
  如果关闭ICP优化,执行计划的Extra显示为Using where,
  意味着使用order_id = 10900进行索引查找之后,再对结果集进行product_name like \'%00163e0496af%\'的筛选

  

  第二个例子是后面自己想的,为了验证ICP的出现场景,以及确实优于非ICP优化的情况

这一次使用的表是test_order,test_order上的索引为create index idx_userid_order_id_createdate on test_order(user_id,order_id,create_date);
查询语句为:select * from test_order where user_id = 500 and create_date > \'2015-1-1\';
与上面的例子一样,第二个筛选条件是无法直接使用索引的

     首先看两者的执行计划在ICP优化上的区别

  关闭ICP之后的执行计划

  然后分别执在打开与关闭ICP的情况下,观察其执行过程中的profile信息

  查看两个sql执行的详细信息,也即分别在打开与关闭ICP优化的情况下,如下,在stage/sql/Sending data环节有超过一个数量级的差异。
  也就意味着通过ICP机制的优化,server 层和 engine 层之间数据交互的次数减少。

  

  引用MySQL · 特性分析 · Index Condition Pushdown (ICP)中的一句话
  在二级索引是复合索引且前面的条件过滤性较低的情况下,打开 ICP 可以有效的降低 server 层和 engine 层之间交互的次数,从而有效的降低在运行时间。

 

  最后,再思考一个问题,
  对于select * from test_orderdetail where order_id = 10900 and product_name like \'%00163e0496af%\';这个查询,
  如果order_id 包含在一个二级索引中,但是product_name 没有包含在这个二级索引中,MySQL会不会采用ICP的方式进行优化?
  答案是否定的。
  因为ICP的前提两个查询条件包被索引覆盖,但是次选条件无法直接使用索引查找,如果次选条件没有被索引覆盖,是无法得知次选条件的值的,也就无从 索引条件下推优化了。

  

 

  

 

Multi-Range Read(MRR)

非MRR优化下存在的问题:
首先了解一点背景知识:MySQL的Innodb表都是聚集索引表,没有显式指定聚集索引的情况下,会自动生成一个聚集索引。
在使用二级索引(或者说是非聚集索引)进行范围查询的条件下,二级索引会根据其B树结构的叶子节点存储的聚集索引进行数据的查找(回表操作),
但是符合条件的数据(二级索引超找的数据)有可能是随机分布在聚集索引B树的任何一个部分,这样就可能存在表上过多的随机IO。
当表非常大的时候,每一行的查找过程都需要在磁盘上随机进行,可能会对性能造成影响。

举个例子,
如下图,参考蓝线的移动轨迹,二级索引查找到的目标数据行的物理位置为1,2,3,4(主要的是以何种顺序去获取这四个位置的数据,可以随机的方式获取,也可以顺序的方式获取,讲究就在这一点)
在查找这四个位置的数据的时候,如果直接按照二级索引对应的聚集索引的顺序查找,
由于二级索引排序的情况下,其对应的聚集索引的顺序可能是随机的,那么其对应的数据的物理位置也就是随机的了
如果按照二级索引的顺去回表超找对应的数据行,那么这个过程就需要随机IO查找。
这种查询方式的缺点,可以理解为在查询这四行数据的过程中,在物理位置差异较大的情况下,需要磁头来回摆臂来实现(随机IO读取)。

MRR多范围读取优化的目的是通过对记录的读取请求进行排序,然后再读取数据行的时候以顺序IO的方式进行,避免随机IO
究竟是对哪个字段排序?个人认为可以理解成二级索引范围查找到的对应的聚集索引的key值进行排序。
有序扫描的过程可以认为是:

(1)通过非聚集索引找到目标数据的聚集索引的key值
(2)对通过二级索引找到的目标数据的聚集索引的key值排序,此时聚集索引与物理位置一一对应。
(3)(回表的过程)通过二级索引对应的有序的聚集索引,执行一个有序的磁盘扫描来获取数据,从而来加快读取数据的速度。

顺序读磁盘通常会更快,当然也不是说这种方式的效率总是较高的,凡事有利必有弊,也有例外的情况

1,如果扫描的是一个较小的数据范围,并且目标数据已经在磁盘的缓存当中,MRR的唯一影响是为了缓冲/排序额外的增加了一些CPU开销。
2,order by *** LIMIT n查询,当n值比较小的时候,可能会变的更慢,
   原因是 MRR试图通过顺序读盘的方式(来或取数据),可能一开始读取到的数据并非总是排在(order by ***)符合前N条的。
3,MRR是一个实现过程,个人理解,极端情况下,如果MySQL不知道目标数据的行数,
   如果仅仅只有一行,依然要进行排序操作,然后回表读取数据行,这种情况下也是得不偿失的。

  打开MRR优化
  set global optimizer_switch = \'mrr=on,mrr_cost_based=off\';

  启用MRR优化的前提是要进行书签超找,也即要回表,如果不需要回表的话,二级索引本身就可以查询出来需要的字段了,没有随机IO的机会的所谓了。

  如下截图,如果去掉order_status,也就意味着无需回表查询,那么就不会出现MRR优化了。

  同时,一旦出现MRR优化,查询出来的结果的顺序,必然是按照聚集索引来排序的,这个原理应该是不难理解的。

  

  当然MRR优化也有在表关联情况下的优化措施,原理大同小异。

总结:

    Index Condition Pushdown(索引条件下推)和Multi-Range Read(多范围读)都是MySQL为了提高查询优化而备用的选项,属于MySQL5.6里面的新特性。
    无奈楼主接触MySQL不久,见识不够,很是觉得新鲜,高手勿喷。
    两者的共同的特点都是在使用索引超找(或者索引范围扫描)的过程中的一些优化措施。
    这些优化措施可以在二级索引查找(索引范围扫描)的过程中优化查询动作的行为,
    当然这些优化措施并非总是万能的,允许用户显式打开或者关闭,给用户充分的自由,然而自由也并非完全没有问题,这也要求用户在做相关优化的时候需要进行充分的权衡和考虑。

 

参考:

    https://mariadb.com/kb/en/mariadb/multi-range-read-optimization/
    http://blog.itpub.net/22664653/viewspace-1673682/
    http://blog.itpub.net/22664653/viewspace-1678779/
       http://mysql.taobao.org/monthly/2015/12/08/

     以及各种网上搜索……

 

最后,mariadb官方这几张图非常赞,对理解问题很有帮助,先盗下来,备用(无耻一笑,O(∩_∩)O~),

突然又想到做人了,为什么一定要直来直去呢,很多时候是欲速则不达,迂回一下,暂时停下来,好好计划计划再出发,未必是坏事。

 

以上是关于Multi-Range Read优化的主要内容,如果未能解决你的问题,请参考以下文章

浅析MySQL中的Index Condition Pushdown (ICP 索引条件下推)和Multi-Range Read(MRR 索引多范围查找)查询优化

浅析MySQL中的Index Condition Pushdown (ICP 索引条件下推)和Multi-Range Read(MRR 索引多范围查找)查询优化

MySQL Multi-Range Read

MySQL 5.6新特性 -- Multi-Range Read

在 pyspark 中处理大数据的优化

nginx高并发优化之事件驱动模块设置