MySQL InnoDB MRR优化指南

前言

MRR 是 Multi-Range Read 的简写，目的是减少磁盘随机访问，将随机访问转化为较为顺序的访问。适用于 range/ref/eq_ref 类型的查询。

实现原理：

1、在二级索引查找后，根据得到的主键到聚簇索引找出需要的数据。

2、二级索引查找得到的主键的顺序是不确定的，因为二级索引的顺序与聚簇索引的顺序不一定一致；

3、如果没有 MRR，那么在聚簇索引查找时就可能出现乱序读取数据页，这对于机械硬盘是及其不友好的。

4、MRR 的优化方式：

  • 将查找到的二级索引键值放在一个缓存中；
  • 将缓存中的键值按照 主键 进行排序；
  • 根据排序后的主键去聚簇索引访问实际的数据文件。

5、当优化器使用了 MRR 时，执行计划的 Extra 列会出现 “Using MRR” 。

6、如果查询使用的二级索引的顺序本身与结果集的顺序一致，那么使用 MRR 后需要对得到的结果集进行排序。

使用 MRR 还可以减少缓冲池中页被替换的次数，批量处理对键值的查询操作。

可以使用命令 select @@optimizer_switch; 查看是否开启了 MRR：

index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,engine_condition_pushdown=on,index_condition_pushdown=on,mrr=off,mrr_cost_based=on,block_nested_loop=on,batched_key_access=off,materialization=on,semijoin=on,loosescan=on,firstmatch=on,duplicateweedout=on,subquery_materialization_cost_based=on,use_index_extensions=on,condition_fanout_filter=on,derived_merge=on,use_invisible_indexes=off,skip_scan=on

mrr_cost_based=on 表示是否通过 cost based 的方式来选择使用 MRR 。

用 set @@optimizer_switch='mrr=on/off'; 命令开启或关闭 MRR 。

select @@read_rnd_buffer_size ; 参数用来控制键值的缓冲区大小，默认 256K，当大于该参数值时，执行器根据主键对已缓存的数据进行排序，然后再通过主键取得行数据。

总结

以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，谢谢大家对我们的支持。

赞 (0)

相关推荐

  • MySQL优化之InnoDB优化

    学习计划很容易就被打断,坚持也不容易.最近公司里开会,要调整业务方向,建议学习NodeJS.NodeJS之前我就会一点,但是没有深入研究.Node的语法和客户端Js基本上是一样的,这半年来很少开发有客户端的东西.本来JS基础还行的我,也对这块的知识陌生了.看起来知识都是用进废退的,不常用了,过不了多久就会遗忘.所以又重新复习了JS的相关知识.学习了Node的服务器与socket知识.MySQL的计划就这样的搁浅起来,星期天的时候吃吃喝喝睡睡,早上又懒的要命,熬着熬着就熬到了下午.废话不多说了,继

  • 关于mysql中innodb的count优化问题分享

    一般采用二级索引去count:比如:id 是pk aid是secondary index 采用 复制代码 代码如下: select count(*) from table where id >=0;或select count(*) from table; 效果是一样的,都是默认使用pk索引,且都要全表扫描,虽然第一种性能可能高一些,但是没有明显区别. 但是如果用secondary index 复制代码 代码如下: select count(*) from table where aid>=0;

  • MySql优化之InnoDB,4GB内存,多查询的my.ini中文配置方案详解

    本文是一个针对 4G 内存系统(主要运行只有 InnoDB 表的 MySQL 并使用几个连接数执行复杂的查询)的 MySQL 配置文件方案 #开始配置信息 #描述:4GB 内存.只有 InnoDB.ACID.几个连接数.繁重的查询 #类型:系统 #结束配置信息 # 你可以复制该文件到 /etc/my.cnf 以设置全局的选项,复制到 mysql-data-dir/my.cnf 以设置服务器特有的选项(在本安装中该目录是 C:mysqldata ),复制到 ~/.my.cnf 以设置用户特有的选项

  • Mysql5.5 InnoDB存储引擎配置和优化

    环境为CentOS系统,1G内存,Mysql5.5.30.在/etc/my.cnf内添加: 复制代码 代码如下: skip-external-lockingskip-name-resolvemax_connections = 1024query_cache_size = 16Msort_buffer_size = 1Mtable_cache = 256innodb_buffer_pool_size = 128Minnodb_additional_mem_pool_size = 4Minnodb_

  • 修改Innodb的数据页大小以优化MySQL的方法

    我们知道Innodb的数据页是16K,而且是一个硬性的规定,系统里没更改的办法,希望将来MySQL也能也Oracle一样支持多种数据页的大小. 但实际应用中有时16K显的有点大了,特别是很多业务在Oracle或是SQL SERVER运行的挺好的情况下迁到了MySQL上发现IO增长太明显的情况下, 就会想到更改数据页大小了. 实际上innodb的数据页大小也是可以更改的,只是需要在源码层去更改,然后重新rebuild一下MySQL.     更改办法:     (以MySQL-5.1.38源码为例

  • MySQL InnoDB MRR优化指南

    前言 MRR 是 Multi-Range Read 的简写,目的是减少磁盘随机访问,将随机访问转化为较为顺序的访问.适用于 range/ref/eq_ref 类型的查询. 实现原理: 1.在二级索引查找后,根据得到的主键到聚簇索引找出需要的数据. 2.二级索引查找得到的主键的顺序是不确定的,因为二级索引的顺序与聚簇索引的顺序不一定一致: 3.如果没有 MRR,那么在聚簇索引查找时就可能出现乱序读取数据页,这对于机械硬盘是及其不友好的. 4.MRR 的优化方式: 将查找到的二级索引键值放在一个缓存

  • Mysql Innodb存储引擎之索引与算法

    Mysql Innodb存储引擎之索引与算法

    目录 一.概述 二.数据结构与算法 1.二分查找 2.二叉查找树和平衡二叉树 1)二叉查找树 2)平衡二叉树 三.B+树 1.B+树完整定义 2.关于 M 和 L的选定案例 四.B+树索引 1.聚集索引 2.辅助索引 五.关于 Cardinality 值 1.Cardinality定义 2.Cardinality的更新 六.B+树索引的使用 1.联合索引 2.覆盖索引 3.优化器选择不使用索引的情况 4.索引提示 5.Multi-Range Read 优化 (MRR) 6.Index Condi

  • MySQL查询性能优化武器之链路追踪

    MySQL查询性能优化武器之链路追踪

    目录 前言 1. 查看optimizer trace配置 2. 开启optimizer trace 3. 线上问题复现 3. 使用optimizer trace 前言 MySQL优化器可以生成Explain执行计划,我们可以通过执行计划查看是否使用了索引,使用了哪种索引? 但是到底为什么会使用这个索引,我们却无从得知. 好在MySQL提供了一个好用的分析工具 — optimizer trace(优化器追踪),可以帮助我们查看优化器生成执行计划的整个过程,以及做出的各种决策,包括访问表的方法.各种

  • MyISAM和InnoDB引擎优化分析

    这几天喻名堂在学习mysql数据库的优化并在自己的服务器上进行设置,喻名堂主要学习了MyISAM和InnoDB两种引擎的优化方法,它们各有优缺点,一般在实际应用中将两种引擎结合起来使用效果会更好.喻名堂测试的硬件配置以及软件环境如下: 服务器型号:IBM S226 CPU:至强四核 内存:4G 硬盘:两个80G做RAID1 系统:windows server 2003 SP1 32位企业版 Mysql版本:5.5 根据自己服务器的实际情况,优化过和参数如下: 一.公共选项 skip-extern

  • 分享101个MySQL调试与优化技巧

    分享101个MySQL调试与优化技巧

    MySQL是一个功能强大的开源数据库.随着越来越多的数据库驱动的应用程序,人们一直在推动MySQL发展到它的极限.这里是101条调节和优化MySQL安装的技巧.一些技巧是针对特定的安装环境的,但这些思路是通用的.我已经把他们分成几类,来帮助你掌握更多MySQL的调节和优化技巧. MySQL 服务器硬件和操作系统调节: 1. 拥有足够的物理内存来把整个InnoDB文件加载到内存中--在内存中访问文件时的速度要比在硬盘中访问时快的多. 2. 不惜一切代价避免使用Swap交换分区 – 交换时是从硬盘读

  • 解析MySQL数据库性能优化的六大技巧

    数据库表表面上存在索引和防错机制,然而一个简单的查询就会耗费很长时间.Web应用程序或许在开发环境中运行良好,但在产品环境中表现同样糟糕.如果你是个数据库管理员,你很有可能已经在某个阶段遇到上述情况.因此,本文将介绍对MySQL进行性能优化的技巧和窍门. 1.存储引擎的选择如果数据表需要事务处理,应该考虑使用InnoDB,因为它完全符合ACID特性.如果不需要事务处理,使用默认存储引擎MyISAM是比较明智的.并且不要尝试同时使用这两个存储引擎.思考一下:在一个事务处理中,一些数据表使用Inno

  • Mysql数据库性能优化三（分表、增量备份、还原）

    Mysql数据库性能优化三（分表、增量备份、还原）

    接上篇Mysql数据库性能优化二 对表进行水平划分     如果一个表的记录数太多了,比如上千万条,而且需要经常检索,那么我们就有必要化整为零了.如果我拆成100个表,那么每个表只有10万条记录.当然这需要数据在逻辑上可以划分.一个好的划分依据,有利于程序的简单实现,也可以充分利用水平分表的优势.比如系统界面上只提供按月查询的功能,那么把表按月拆分成12个,每个查询只查询一个表就够了.如果非要按照地域来分,即使把表拆的再小,查询还是要联合所有表来查,还不如不拆了.所以一个好的拆分依据是 最重要的

  • MySQL中索引优化distinct语句及distinct的多字段操作

    MySQL通常使用GROUPBY(本质上是排序动作)完成DISTINCT操作,如果DISTINCT操作和ORDERBY操作组合使用,通常会用到临时表.这样会影响性能. 在一些情况下,MySQL可以使用索引优化DISTINCT操作,但需要活学活用.本文涉及一个不能利用索引完成DISTINCT操作的实例. 实例1 使用索引优化DISTINCT操作 create table m11 (a int, b int, c int, d int, primary key(a)) engine=INNODB;

  • MySQL性能全面优化方法参考,从CPU,文件系统选择到mysql.cnf参数优化

    本文整理了一些MySQL的通用优化方法,做个简单的总结分享,旨在帮助那些没有专职MySQL DBA的企业做好基本的优化工作,至于具体的SQL优化,大部分通过加适当的索引即可达到效果,更复杂的就需要具体分析了,可以参考本站的一些优化案例或者联系我们 1.硬件层相关优化 1.1.CPU相关 在服务器的BIOS设置中,可调整下面的几个配置,目的是发挥CPU最大性能,或者避免经典的NUMA问题: 1.选择Performance Per Watt Optimized(DAPC)模式,发挥CPU最大性能,跑

  • MYSQL中binlog优化的一些思考汇总

    问题 问题1:如何解决事务提交时flush redo log带来的性能损失 WAL是实现事务持久性(D)的一个常用技术,基本原理是将事务的修改记录redo log.redo log顺序追加写入.事务提交时,只需要保证事务的redo log落盘即可,通过redo log的顺序写代替页面的随机写提升数据库系统的性能.但是,该方案必须要求每个事务提交时都将其生成的redo log进行一次刷盘,效率不高. 问题2:binlog和引擎层事务提交的顺序问题 对于单个事务而言,日志写入顺序是先redo log

随机推荐