Multi Range Read 代码路径

简介:
所谓MRR,简单的说就是当使用二级索引进行检索并且查询的列需要回表时,先根据检索到的PK值进行排序,然后再回表依次查询聚集索引,从而避免过多的随机IO。

测试示例:
创建一个简单的表:
CREATE TABLE `x1` (
`a` int(11) NOT NULL AUTO_INCREMENT,
`b` int(11) DEFAULT NULL,
`c` int(11) DEFAULT NULL,
PRIMARY KEY (`a`),
KEY `b` (`b`)
) ENGINE=InnoDB;
插入大量随机数据:
insert into x1 (b,c) select rand()*100, rand()*10000;
insert into x1 (b,c) select rand()*100, rand()*10000 from x1;
insert into x1 (b,c) select rand()*100, rand()*10000 from x1;
……
执行SQL:
root@sb1 04:42:15>set session optimizer_switch=’mrr_cost_based=off';
Query OK, 0 rows affected (0.00 sec)root@sb1 04:42:29>explain select * from x1 where b between 60 and 70 limit 10;
+—-+————-+——-+——-+—————+——+———+——+——–+———————————-+
| id | select_type | table | type  | possible_keys | key  | key_len | ref  | rows   | Extra                            |
+—-+————-+——-+——-+—————+——+———+——+——–+———————————-+
|  1 | SIMPLE      | x1    | range | b             | b    | 5       | NULL | 162690 | Using index condition; Using MRR |
+—-+————-+——-+——-+—————+——+———+——+——–+———————————-+
1 row in set (0.00 sec)
参考代码:MySQL5.6.16
1.优化器阶段:
JOIN::optimize
—> make_join_statistics
     —>get_quick_record_count
          —>SQL_SELECT::test_quick_select
               —>get_key_scans_params
                    —>check_quick_select
                         —>DsMrr_impl::dsmrr_info_const
                              —>handler::multi_range_read_info_const   //计算MRR的COST
2.初始化:
JOIN::exec —>do_select —> sub_select
—>join_init_read_record
     —>QUICK_RANGE_SELECT::reset
          —>ha_innobase::multi_range_read_init
               —>DsMrr_impl::dsmrr_init
                    —>DsMrr_impl::dsmrr_fill_buffer
                         multi_range_read_next
                              handler::read_range_first
                              handler::read_range_next
该步骤会读取请求range的二级索引key范围,并进行快速排序,主函数DsMrr_impl::dsmrr_fill_buffer

 

3.读取聚集索引记录
JOIN::exec —>do_select—>sub_select—>rr_quick—>
QUICK_RANGE_SELECT::get_next
     —>ha_innobase::multi_range_read_next
根据之前排好顺序的Primary Key值,依次读取聚集索引记录

 

相关文章
fetch上传文件报错的问题(multipart: NextPart: EOF)
技术栈 后台: gin(golang) 前端: react+antd+dva 问题 前端这边使用fetch发送http请求的时候,后端解析formData报错: multipart: NextPart: EOF 分析问题 原因是上传文件太小了Content-Length数量太小了,尝试将headers里这字段的value变大,发现实际的请求依然是较小值。
|
8月前
|
JavaScript 前端开发 数据挖掘
node + ts 读取csv文件为二维数组
node + ts 读取csv文件为二维数组
122 0
913 error Component name “home“ should always be multi-word vuemulti-word-component-names
913 error Component name “home“ should always be multi-word vuemulti-word-component-names
129 0
|
JavaScript 前端开发 开发者
Component name “xxx“ should always be multi-word
Component name “xxx“ should always be multi-word
Component name “xxx“ should always be multi-word
|
前端开发
.NET使用HttpClient以multipart/form-data形式post上传文件及其相关参数
.NET使用HttpClient以multipart/form-data形式post上传文件及其相关参数
445 0
.NET使用HttpClient以multipart/form-data形式post上传文件及其相关参数
|
Android开发
storage/emulated/0路径下的File.listFiles返回值为null
storage/emulated/0路径下的File.listFiles返回值为null
667 0
storage/emulated/0路径下的File.listFiles返回值为null
torch.distributed.init_process_group(‘gloo’, init_method=‘file://tmp/somefile’, rank=0, world_size=1
torch.distributed.init_process_group(‘gloo’, init_method=‘file://tmp/somefile’, rank=0, world_size=1
616 0
torch.distributed.init_process_group(‘gloo’, init_method=‘file://tmp/somefile’, rank=0, world_size=1
|
安全 API
Read-only dynamic data
lwn文章翻译,原文[链接](https://lwn.net/Articles/750215/) ## 简介 本文主要讲述的是一种动态内存的只读保护机制。 ## 原文 内核开发者可以对想保护的数据设置为read-only权限,借助于MMU来避免恶意攻击者的篡改。kernel目前已经支持只读内存保护,但这些内存必须在操作系统自举完成前被初始化,所以局限性很大。Igor Stoppa的
988 0
|
Python
使用requests库提交multipart/form-data 格式的请求
前言: Requests是用Python语言编写,基于urllib,采用Apache2 Licensed开源协议的HTTP库。它比urllib更加方便,可以节约我们大量的工作,完全满足HTTP测试需求。
1605 0