[转]MySQL源码:Range和Ref优化的成本评估
MySQL源码:Range和Ref优化的成本评估
在开始介绍index merge/ROR优化之前,打算先介绍MySQL是如何对range/ref做成本评估的。MySQL是基于成本(cost)模型选择执行计划,在多个range,全表扫描,ref之间会选择成本最小的作为最终的执行计划。仍然强烈建议先阅读登博的slide:《查询优化浅析》,文中较为详细的介绍MySQL在range优化时成本的计算。
本文将继续介绍range/ref执行计划选择的一些不容忽略的细节。希望看客能够通过此文能够了解更多细节。
0. 成本计算的总原则
MySQL的一个执行计划,有两部分成本,CPU成本(CPU COST)和IO成本(IO COST)。
总成本 = CPU COST + IO COST
补充说明:(1) IO成本计算不考虑缓存的影响。因为在优化器本身是无法预知需要的数据到底在内存中还是磁盘上。
1. range成本的计算与分析
MySQL使用一颗SEL_ARG的树形结构描述了WHERE条件中的range,如果有多个range,则使用递归的方式遍历SEL_ARG结构,在前面详细的介绍range的红黑树结构,以及MySQL如何遍历之。
接上文,这里将看看,遍历到最后,MySQL如何计算一个简单range的成本。
1.1 range返回的记录数
MySQL首先计算range需要返回都少纪录,通过函数check_quick_select返回对某个索引做range查询大约命中多少条纪录。
found_records= check_quick_select(param, idx, *key, update_tbl_stats);
1.2 CPU COST
#define TIME_FOR_COMPARE 5 // 5 compares == one read
double cpu_cost= (double) found_records / TIME_FOR_COMPARE;
1.3 IO COST
对于InnoDB的二级索引,且不是覆盖扫描:
found_read_time := number of ranges + found_records
这里,found_records是主要部分,number of ranges表示一共有多少个range,这是一个修正值,表示IO COST不小于range的个数。
1.4 全表扫描的成本
具体的,对于InnoDB表,我们来看:
read_time= number of total page + (records / TIME_FOR_COMPARE + 1) + 1.1;
对于InnoDB取值为:主键索引(数据)所使用的page数量(stat_clustered_index_size)
对于MyISAM取值为:stats.data_file_length/IO_SIZE + file->tables
1.5 关于range执行计划的分析
这里来看看,range的选择度(selectivty)大概为多少的时候,会放弃range优化,而选择全表扫描。下面时一个定量的分析:
(1) 假设总记录数为R;range需要返回的纪录数为r
(2) 假设该表的总页面数(IO COST)为P;单个页面纪录数为c
在我的测试案例中,P=4,R=1016 ,有
也就是说这个案例中,如果选择度(selectivity)高于17.1%就会放弃range优化,而走全表扫描。这里纪录数超过1016*0.171=173时将放弃range优化。
1.6 验证
MySQL通过函数check_quick_select返回range可能扫描的记录数,所以,这里通过对该函数设置断点,并手动设置返回值,通过此来验证上面对selectivity的计算,详细地:
上面可以看到,如果range命中的记录数超过173的时候,就会放弃range,选择全表扫描。
1.7 一些限制
(1) 无论时InnoDB还是MyISAM的scan_time,range返回的记录数都不是精确值,而且对于InnoDB,总记录数也不是精确值,所以上面只是一个High level的预估。
(2) 上面案例中,条纪录很短,所以看到总page很少,实际情况,单条纪录更大,也就是上面的单个页面纪录数为c更小,所以通常选择度更高的时候,才会选择全表扫描。
2. ref成本的计算与分析
2.1 ref返回的记录数
ref优化的时候,计算返回的记录数从代码上来看要复杂很多,但是思想很简单。
思路:在range优化阶段,任何等值都会当作范围条件(参考1,参考2)。
对于kp1 = const and kp2 = const这类ref,MySQL将直接使用range优化时返回的结果,这个结果是通过存储引擎接口records_in_range返回。
还有一类较为特殊的ref,kp1 = const and kp2 > const,对于此类ref,range优化的时候,会使用两个索引列,但是ref只能用一个索引列。这时,ref首先根据索引统计信息(show index from users中Cardinality的值)预估。因为这里有range优化的值,还会做一次修正,因为range使用了更多的索引字段。修正逻辑为:如果发现索引统计信息太过保守(例如数据分布不均匀时,遇到一个热点),这时会用range优化的值修正。
所以,返回的纪录数,使用如下代码获取:
records= keyinfo->rec_per_key[max_key_part-1]
if(records < (double)table->quick_rows[key]...)
records= (double)table->quick_rows[key];
2.2 CPU COST
CPU COST := records/(double) TIME_FOR_COMPARE;
2.3 IO COST
ref在做IO成本评估的时候,基本同range相同,ref命中多少纪录则需要多少个IO COST。但是跟range优化打不同的是,这里做了一个修正(range优化并没有做),也是IO COST最坏不会超过全表扫描IO消耗的3倍(或者总记录数除以10),有下面的代码:
s->worst_seeks= min((double) s->found_records / 10,
(double) s->read_time*3);
IO COST := record_count*min(tmp,s->worst_seeks);
这里record_count是前一次关联后的记录数。tmp是当前ref命中的记录数。这个修正的逻辑是很好理解的:即使加上索引扫描其io cost仍然是有限度的。因为range的评估并没有加上这个修正,所以就导致了一些奇怪的事情发生了,后面我们再详细分析这一点。
2.4 全表扫描的成本
简单版本(不考虑多表关联):
scan_time() + s->records/TIME_FOR_COMPARE
scan_time()为存储引擎返回的全表扫描IO次数;s->records为存储引擎维护的单表总纪录数。
复杂版本(有多表关联):
假设前面关联后的纪录数为record_count,当前表的where条件将过滤后剩余3/4的纪录(不满足where条件的为1/4),并将这个值记为rnd_records。
(s->records - rnd_records)/TIME_FOR_COMPARE +
record_count * (rnd_records/TIME_FOR_COMPARE)
这里假设将过滤1/4数据,实际代码中还将做一次修正,如果有range计算,假设其命中q条纪录,那么就认为将过滤s->records-q条纪录。
2.5 关于ref执行计划的分析
上面的分析,可以看到,ref成本有一部分是取min函数的,为了分析ref和全表扫描的临界条件,为了简化做下面的假设:
(1) scan_time()*3 < s->records / 10
(2) scan_time()*3 < r
第一个条件表示约30条纪录一个page;第二个条件是ref命中的记录数为总页面的3倍。
那么放弃ref全表扫描的条件是:
scan_time()*3 + r/5 > scan_time() + R/5
即:
scan_time()*2 > (R-r)/5
scan_time() > (R-r)/10
具体的:
(1) 假设总记录数为R;ref需要返回的纪录数为r
(2) 假设该表的总页面数(IO COST)为P;单个页面纪录数为c
那么range的代价超过全表扫描代价,则有:
在我的测试案例中,P=6.4,R=900 ,有
对于具体的案例,由于取整的问题,会和上面有小小的偏差:
3*((int)6.39) + r/5 > 6.39453125 + 900/5
r > 841.97
2.6 验证
这里再通过gdb修改r的值来验证,因为ref命中纪录的预估是取range的计算值,所以:
gdb) set s->table->quick_rows[1]=841
(gdb) croot@test 04:37:16>explain select * from users where reg_date = '2012-09-21 12:00:00';
+----+-------------+-------+------+---------------+-------------+---------+-------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+------+---------------+-------------+---------+-------+------+-------------+
| 1 | SIMPLE | users | ref | IND_REGDATE | IND_REGDATE | 9 | const | 841 | Using where |
+----+-------------+-------+------+---------------+-------------+---------+-------+------+-------------+
1 row in set (47.61 sec)(gdb) set s->table->quick_rows[1]=842
(gdb) croot@test 04:38:46>explain select * from users where reg_date = '2012-09-21 12:00:00';
+----+-------------+-------+------+---------------+------+---------+------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+------+---------------+------+---------+------+------+-------------+
| 1 | SIMPLE | users | ALL | IND_REGDATE | NULL | NULL | NULL | 900 | Using where |
+----+-------------+-------+------+---------------+------+---------+------+------+-------------+
另一个结论是,如果当条记录很小,单个页面的记录数很多的话,只有选择度(selectivity)非常高的时候,MySQL才会放弃ref,走全表扫描,这也是,Vadim在2006年吐槽MySQL的一点。
3. 上面计算的局限性
上面的推倒尝试介绍一些通用的情况,但是实际上优化器中计算ref/range的成本时,会有一些不同:
(1) 无论时InnoDB还是MyISAM的scan_time,range返回的记录数都不是精确值,而且对于InnoDB,总记录数也不是精确值,所以上面只是一个High level的预估
(2) 上面案例中,条纪录很短,所以看到总page很少,实际情况,单条纪录更大,也就是上面的单个页面纪录数为c更小,所以通常选择度更高的时候,才会选择全表扫描。
(3) 上面的计算,都不是覆盖扫描的情况,覆盖扫描的时候,成本计算与上面略有不同
(4) 上面都是使用gdb修改某些值的方式来验证。如果想通过创建一个表,够造某个索引的区分度/选制度,因为scan_time和返回的记录数都是预估的,这样的方式是不行的
(5) (update) range的cost计算,最终的公式是:#rows + (#rows/5)*2 + 1 解释如下,
** #rows 为IO成本,因为读取的记录都需要回表查找完整记录,而这些都是离散IO,所以多少条记录,多少个IO
** (#rows/5)*2 是CPU成本,分两部分,第一部分是扫描索引时,确定在查找范围内;第二部分是找到记录后判断是否满足WHERE条件;(这部分成本,在range analysis的时候没有计算)
** 1是一个修正值,防止0成本出现
4. 案例中使用的数据和表
CREATE TABLE `users` (
`id` int(11) NOT NULL, `nick` varchar(32) DEFAULT NULL,
`reg_date` datetime DEFAULT NULL,
KEY `IND_NICK` (`nick`),
KEY `IND_REGDATE` (`reg_date`),
KEY `IND_ID` (`id`) ) ENGINE=MyISAM
for id in `seq 1 886`;\
do mysql -uroot test -e\
"insert into users values($id,char(round(ord('A') + rand()*(ord('z')-ord('A')))),\ '2012-09-21 12:00:00')" ;done
for id in `seq 887 900`;\
do mysql -uroot test -e\
"insert into users values($id,char(round(ord('A') + rand()*(ord('z')-ord('A')))),\ '2012-09-20 12:00:00')" ;done
[转]MySQL源码:Range和Ref优化的成本评估的更多相关文章
- Dubbo入门到精通学习笔记(十九):MySQL源码编译安装、MySQL主从复制的配置
文章目录 MySQL 源码编译安装(CentOS-6.6+MySQL-5.6) 一.服务器配置: 二.源码安装 MySQL5.6.26: MySQL主从复制的配置 环境 依赖课程 MySQL 主从复制 ...
- [源码解析] PyTorch分布式优化器(1)----基石篇
[源码解析] PyTorch分布式优化器(1)----基石篇 目录 [源码解析] PyTorch分布式优化器(1)----基石篇 0x00 摘要 0x01 从问题出发 1.1 示例 1.2 问题点 0 ...
- [源码解析] PyTorch分布式优化器(3)---- 模型并行
[源码解析] PyTorch分布式优化器(3)---- 模型并行 目录 [源码解析] PyTorch分布式优化器(3)---- 模型并行 0x00 摘要 0x01 前文回顾 0x02 单机模型 2.1 ...
- Linux(CentOS或RadHat)下MySQL源码安装
安装环境: CentOS6.3 64位 软件: Mysql-5.6 所需包: gcc/g++ :MySQL 5.6开始,需要使用g++进行编译.cmake :MySQL 5.5开始,使用cmake进 ...
- maridb\mysql 源码安装,以10.1.26版本为例
mysql 源码安装(mariadb 10.1.26) 1.环境部署 1 安装cmake 源码安装三部曲或者yum install cmake2安装依赖包yum install -y ncurses- ...
- MySQL源码解析之执行计划
MySQL源码解析之执行计划 MySQL执行计划介绍 MySQL执行计划代码概览 MySQL执行计划总结 一.MySQL执行计划介绍 在MySQL中,执行计划的实现是基于JOIN和QEP_TAB这两个 ...
- mysql源码解读之配置文件
要研究mysql,最好的资源莫过于源码了,所以本人打算通过调试源码的方式来深入理解mysql的点点滴滴.搭建mysql调试环境很简单,从官方下载mysql源码,利用cmake工具生成工程即可.为了方便 ...
- MySQL源码分析以及目录结构 2
原文地址:MySQL源码分析以及目录结构作者:jacky民工 主要模块及数据流经过多年的发展,mysql的主要模块已经稳定,基本不会有大的修改.本文将对MySQL的整体架构及重要目录进行讲述. 源码结 ...
- MySQL源码分析以及目录结构
原文地址:MySQL源码分析以及目录结构作者:jacky民工 主要模块及数据流经过多年的发展,mysql的主要模块已经稳定,基本不会有大的修改.本文将对MySQL的整体架构及重要目录进行讲述. 源码结 ...
随机推荐
- php 通过stomp协议连接ActiveMQ
一.安装php的stomp扩展 http://pecl.php.net/package/stomp 如:stomp-2.0.0.tgz > tar xf stomp-1.0.9.tgz > ...
- 异常处理 day 30
异常处理 一 错误和异常 二 异常处理 2.1 什么是异常处理? 2.2 为何要进行异常处理? 2.3 如何进行异常处理? 三 什么时候用异常处理 异常和错误 part1:程序中难免出现错误,而错误分 ...
- 集合 day8
一,集合. 集合是无序的,不重复的数据集合,它里面的元素是可哈希的(不可变类型),但是集合本身是不可哈希(所以集合做不了字典的键)的.以下是集合最重要的两点: 去重,把一个列表变成集合,就自动去重了. ...
- (转)数组使用contains
数组使用contains 今天发现一个怪问题,同样是.net3.5环境下的两个项目,一个里支持arr.contains("1"),一个就不支持,代码完全相同也不行.有时在不支持项目 ...
- poj 2777(线段树+lazy思想) 小小粉刷匠
http://poj.org/problem?id=2777 题目大意 涂颜色,输入长度,颜色总数,涂颜色次数,初始颜色都为1,然后当输入为C的时候将x到y涂为颜色z,输入为Q的时候输出x到y的颜色总 ...
- HDU_1142(最短路 + dfs)
Jimmy experiences a lot of stress at work these days, especially since his accident made working dif ...
- Android.HowToDesignPluginArchitectureInAndroidApp
There is a tools called "dx", this tool can transfer Java Binary Code into Android Dalvik ...
- 20172325 2018-2019-1 《Java程序设计》第二周学习总结
20172325 2018-2019-1 <Java程序设计>第二周学习总结 教材学习内容总结 3.1集合 集合是一种聚集.组织了其他对象的对象.集合可以分为两大类:线性集合和非线性集合. ...
- Intellij idea 系列教程之常用配置项
Intellij idea 系列教程之常用配置项 Intellij idea 系列教程目录(https://www.cnblogs.com/binarylei/p/10347600.html) Lan ...
- Android相关概念
2017-06-02 armeabi就是针对普通的或旧的arm v5 cpu,armeabi-v7a是针对有浮点运算或高级扩展功能的arm v7 cpu. armeabi-v7a(32位ARM设备), ...