MySQL 执行一个查询可以有不同的执行方案,它会选择其中成本最低,或者
说代价最低的那种方案去真正的执行查询。不过我们之前对成本的描述是非常模
糊的,其实在 MySQL 中一条查询语句的执行成本是由下边这两个方面组成的:
I/O 成本
我们的表经常使用的 MyISAM、InnoDB 存储引擎都是将数据和索引都存储到
磁盘上的,当我们想查询表中的记录时,需要先把数据或者索引加载到内存中然
后再操作。这个从磁盘到内存这个加载的过程损耗的时间称之为 I/O 成本。
CPU 成本
读取以及检测记录是否满足对应的搜索条件、对结果集进行排序等这些操作
损耗的时间称之为 CPU 成本。
对于 InnoDB 存储引擎来说,页是磁盘和内存之间交互的基本单位,MySQL
规定读取一个页面花费的成本默认是 1.0,读取以及检测一条记录是否符合搜索
条件的成本默认是 0.2。1.0、0.2 这些数字称之为成本常数,这两个成本常数我
们最常用到,当然还有其他的成本常数。
注意,不管读取记录时需不需要检测是否满足搜索条件,其成本都算是 0.2。
在一条单表查询语句真正执行之前,MySQL 的查询优化器会找出执行该语句
所有可能使用的方案,对比之后找出成本最低的方案,这个成本最低的方案就是
所谓的执行计划,之后才会调用存储引擎提供的接口真正的执行查询,这个过程
总结一下就是这样:
1、根据搜索条件,找出所有可能使用的索引
2、计算全表扫描的代价
3、计算使用不同索引执行查询的代价
4、对比各种执行方案的代价,找出成本最低的那一个
下边我们就以一个实例来分析一下这些步骤,单表查询语句如下:
SELECT * FROM order_exp WHERE order_no IN ('DD00_6S', 'DD00_9S',
'DD00_10S') AND expire_time> '2021-03-22 18:28:28' AND expire_time<=
'2021-03-22 18:35:09' AND insert_time> expire_time AND order_note LIKE '%7 排
1%' AND order_status = 0;
乍看上去有点儿复杂,我们一步一步分析一下。
SHOW TABLE STATUS LIKE 'order_exp'\G
出现了很多统计选项,但我们目前只需要两个:
Rows
本选项表示表中的记录条数。对于使用 MyISAM 存储引擎的表来说,该值是
准确的,对于使用 InnoDB 存储引擎的表来说,该值是一个估计值。从查询结果
我们也可以看出来,由于我们的 order_exp 表是使用 InnoDB 存储引擎的,所以
虽然实际上表中有 10567 条记录,但是 SHOW TABLE STATUS 显示的 Rows 值只有
10350 条记录。
Data_length
本选项表示表占用的存储空间字节数。使用 MyISAM 存储引擎的表来说,该
值就是数据文件的大小,对于使用 InnoDB 存储引擎的表来说,该值就相当于聚
簇索引占用的存储空间大小,也就是说可以这样计算该值的大小:
TIPS:我们前边说过表中的记录其实都存储在聚簇索引对应 B+树的叶子节点
中,所以只要我们通过根节点获得了最左边的叶子节点,就可以沿着叶子节点组
成的双向链表把所有记录都查看一遍。
也就是说全表扫描这个过程其实有的 B+树非叶子节点是不需要访问的,但
是 MySQL 在计算全表扫描成本时直接使用聚簇索引占用的页面数作为计算 I/O
成本的依据,是不区分非叶子节点和叶子节点的。
3. 计算使用不同索引执行查询的代价
从第 1 步分析我们得到,上述查询可能使用到 idx_order_no,idx_expire_time
这两个索引,我们需要分别分析单独使用这些索引执行查询的成本,最后还要分
析是否可能使用到索引合并。这里需要提一点的是,MySQL 查询优化器先分析使
用唯一二级索引的成本,再分析使用普通索引的成本,我们这里两个索引都是普
通索引,先算哪个都可以。我们也先分析 idx_expire_time 的成本,然后再看使用
idx_order_no 的成本。
使用 idx_expire_time 执行查询的成本分析
idx_expire_time 对应的搜索条件是:expire_time> ‘2021-03-22 18:28:28’ AND
expire_time<= ‘2021-03-22 18:35:09’ ,也就是说对应的范围区间就是:
(‘2021-03-22 18:28:28’ , ‘2021-03-22 18:35:09’ )。
思考题:扫描区间怎么样从我们复杂的 SQL 语句里提取出来?前面已经讲过
了,不记得的同学回看一下章节《3.2.3.深入思考索引在查询中的使用》。
使用 idx_expire_time 搜索会使用用二级索引 + 回表方式的查询,MySQL 计
算这种查询的成本依赖两个方面的数据:
1、范围区间数量
不论某个范围区间的二级索引到底占用了多少页面,查询优化器认为读取索
引的一个范围区间的 I/O 成本和读取一个页面是相同的。本例中使用
idx_expire_time 的范围区间只有一个,所以相当于访问这个范围区间的二级索引
付出的 I/O 成本就是:1 x 1.0 = 1.0
2、需要回表的记录数
优化器需要计算二级索引的某个范围区间到底包含多少条记录,对于本例来
说就是要计算 idx_expire_time 在(‘2021-03-22 18:28:28’ ,‘2021-03-22 18:35:09’)
这个范围区间中包含多少二级索引记录,计算过程是这样的:
步骤 1:先根据 expire_time> ‘2021-03-22 18:28:28’这个条件访问一下
idx_expire_time 对应的 B+树索引,找到满足 expire_time> ‘2021-03-22 18:28:28’ 这个条件的第一条记录,我们把这条记录称之为区间最左记录。我们前头说过在
B+数树中定位一条记录的过程是很快的,是常数级别的,所以这个过程的性能消
耗是可以忽略不计的。
步骤 2:然后再根据 expire_time<= ‘2021-03-22 18:35:09’这个条件继续从
idx_expire_time 对应的 B+树索引中找出最后一条满足这个条件的记录,我们把
这条记录称之为区间最右记录,这个过程的性能消耗也可以忽略不计的。
步骤 3:如果区间最左记录和区间最右记录相隔不太远(在 MySQL 5.7 这个
版本里,只要相隔不大于 10 个页面即可),那就可以精确统计出满足 expire_time>
‘2021-03-22 18:28:28’ AND expire_time<= ‘2021-03-22 18:35:09’条件的二级索引记
录条数。否则只沿着区间最左记录向右读 10 个页面,计算平均每个页面中包含
多少记录,然后用这个平均值乘以区间最左记录和区间最右记录之间的页面数量
就可以了。那么问题又来了,怎么估计区间最左记录和区间最右记录之间有多少
个页面呢?解决这个问题还得回到 B+树索引的结构中来。
我们假设区间最左记录在页 b 中,区间最右记录在页 c 中,那么我们想计算
区间最左记录和区间最右记录之间的页面数量就相当于计算页b和页 c 之间有多
少页面,而它们父节点中记录的每一条目录项记录都对应一个数据页,所以计算
页 b 和页 c 之间有多少页面就相当于计算它们父节点(也就是页 a)中对应的目
录项记录之间隔着几条记录。在一个页面中统计两条记录之间有几条记录的成本
就很小了。
explain SELECT * FROM order_exp WHERE expire_time> '2021-03-22 18:28:28' AND expire_time<= '2021-03-22 18:35:09';
读取这 39 条二级索引记录需要付出的 CPU 成本就是:
39 x 0.2 + 0.01 = 7.81
其中 39 是需要读取的二级索引记录条数,0.2 是读取一条记录成本常数,0.01
是微调。
在通过二级索引获取到记录之后,还需要干两件事儿:
1、根据这些记录里的主键值到聚簇索引中做回表操作
MySQL 评估回表操作的 I/O 成本依旧很简单粗暴,他们认为每次回表操作都
相当于访问一个页面,也就是说二级索引范围区间有多少记录,就需要进行多少
次回表操作,也就是需要进行多少次页面 I/O。我们上边统计了使用
idx_expire_time 二级索引执行查询时,预计有 39 条二级索引记录需要进行回表
操作,所以回表操作带来的 I/O 成本就是:
39 x 1.0 = 39 .0
其中 39 是预计的二级索引记录数,1.0 是一个页面的 I/O 成本常数。
2、回表操作后得到的完整用户记录,然后再检测其他搜索条件是否成立
回表操作的本质就是通过二级索引记录的主键值到聚簇索引中找到完整的
用户记录,然后再检测除 expire_time> ‘2021-03-22 18:28:28’ AND expire_time<
'2021-03-22 18:35:09’这个搜索条件以外的搜索条件是否成立。
因为我们通过范围区间获取到二级索引记录共 39 条,也就对应着聚簇索引
中 39 条完整的用户记录,读取并检测这些完整的用户记录是否符合其余的搜索
条件的 CPU 成本如下:
39 x 0.2 =7.8
其中 39 是待检测记录的条数,0.2 是检测一条记录是否符合给定的搜索条
件的成本常数。
所以本例中使用 idx_expire_time 执行查询的成本就如下所示:
I/O 成本:
1.0 + 39 x 1.0 = 40 .0 (范围区间的数量 + 预估的二级索引记录条数)
CPU 成本:
39 x 0.2 + 0.01 + 39 x 0.2 = 15.61 (读取二级索引记录的成本 + 读取并检测
回表后聚簇索引记录的成本)
综上所述,使用 idx_expire_time 执行查询的总成本就是:
40 .0 + 15.61 = 55.61
使用 idx_order_no 执行查询的成本分析
idx_order_no 对应的搜索条件是:order_no IN (‘DD00_6S’, ‘DD00_9S’,
‘DD00_10S’),也就是说相当于 3 个单点区间。
与使用 idx_expire_time 的情况类似,我们也需要计算使用 idx_order_no 时需
要访问的范围区间数量以及需要回表的记录数,计算过程与上面类似,我们不详
列所有计算步骤和说明了。
范围区间数量
使用 idx_order_no 执行查询时很显然有 3 个单点区间,所以访问这 3 个范围
区间的二级索引付出的 I/O 成本就是:
3 x 1.0 = 3.0
需要回表的记录数
由于使用 idx_expire_time 时有 3 个单点区间,所以每个单点区间都需要查找
一遍对应的二级索引记录数,三个单点区间总共需要回表的记录数是 58。
explain SELECT * FROM order_exp WHERE order_no IN ('DD00_6S', 'DD00_9S',
'DD00_10S');
读取这些二级索引记录的 CPU 成本就是:58 x 0.2 + 0.01 = 11.61
得到总共需要回表的记录数之后,就要考虑:
根据这些记录里的主键值到聚簇索引中做回表操作,所需的 I/O 成本就是:
58 x 1.0 = 58.0
回表操作后得到的完整用户记录,然后再比较其他搜索条件是否成立
此步骤对应的 CPU 成本就是:
58 x 0.2 = 11.6
所以本例中使用 idx_order_no 执行查询的成本就如下所示:
请注意:1、MySQL 的源码中对成本的计算实际要更复杂,但是基本思想和
算法是没错的。
2、在 MySQL 的实际计算中,在和全文扫描比较成本时,使用索引的成本会
去除读取并检测回表后聚簇索引记录的成本,也就是说,我们通过 MySQL 看到
的成本将会是:idx_expire_time 为 47.81(55.61-7.8),idx_order_no 为
72.61(84.21-11.6)。但是 MySQL 比较完成本后,会再计算一次使用索引的成本,
此时就会加上去除读取并检测回表后聚簇索引记录的成本,也就是我们计算出来
的值。
index dive
有时候使用索引执行查询时会有许多单点区间,比如使用 IN 语句就很容易
产生非常多的单点区间,比如下边这个查询(下边查询语句中的…表示还有很多
参数):
SELECT * FROM order_exp WHERE order_no IN ('aa1', 'aa2', 'aa3', ... , 'zzz');
很显然,这个查询可能使用到的索引就是 idx_order_no,由于这个索引并不
是唯一二级索引,所以并不能确定一个单点区间对应的二级索引记录的条数有多
少,需要我们去计算。就是先获取索引对应的 B+树的区间最左记录和区间最右
记录,然后再计算这两条记录之间有多少记录(记录条数少的时候可以做到精确
计算,多的时候只能估算)。MySQL 把这种通过直接访问索引对应的 B+树来计
算某个范围区间对应的索引记录条数的方式称之为 index dive。
有零星几个单点区间的话,使用 index dive 的方式去计算这些单点区间对应
的记录数也不是什么问题,如果 IN 语句里 20000 个参数怎么办?
这就意味着 MySQL 的查询优化器为了计算这些单点区间对应的索引记录条
数,要进行 20000 次 index dive 操作,这性能损耗就很大,搞不好计算这些单点
区间对应的索引记录条数的成本比直接全表扫描的成本都大了。MySQL 考虑到了
这种情况,所以提供了一个系统变量 eq_range_index_dive_limit,我们看一下在
MySQL 5.7.21 中这个系统变量的默认值:
show variables like '%dive%';
也就是说如果我们的 IN 语句中的参数个数小于 200 个的话,将使用 index
dive 的方式计算各个单点区间对应的记录条数,如果大于或等于 200 个的话,可
就不能使用 index dive 了,要使用所谓的索引统计数据来进行估算。怎么个估算
法?
像会为每个表维护一份统计数据一样,MySQL 也会为表中的每一个索引维护
一份统计数据,查看某个表中索引的统计数据可以使用 SHOW INDEX FROM 表名
的语法,比如我们查看一下 order_exp 的各个索引的统计数据可以这么写:
show index from order_exp;
属性名 描述
insert_time
, order_status
, expire_time
对应的位置分使用 SHOW TABLE STATUS 展示出的 Rows 值,也就是一个表中有多少条记录。
使用 SHOW INDEX 语句展示出的 Cardinality 属性。
结合上一个 Rows 统计数据,我们可以针对索引列,计算出平均一个值重复
多少次。
一个值的重复次数 ≈ Rows ÷ Cardinality
以 order_exp 表的 idx_order_no 索引为例,它的 Rows 值是 10350,它对应
的 Cardinality 值是 10220,所以我们可以计算 order_no 列平均单个值的重复次数
就是:10350÷ 10220≈ 1.012(条)
此时再看上边那条查询语句:
SELECT * FROM order_exp WHERE order_no IN ('aa1', 'aa2', 'aa3', ... , 'zzz');
假设 IN 语句中有 20000 个参数的话,就直接使用统计数据来估算这些参数
需要单点区间对应的记录条数了,每个参数大约对应 1.012 条记录,所以总共需
要回表的记录数就是:
20000 x 1.012= 21,730
使用统计数据来计算单点区间对应的索引记录条数比 index dive 的方式简单,
但是它的致命弱点就是:不精确!。使用统计数据算出来的查询成本与实际所需
的成本可能相差非常大。
大家需要注意一下,在 MySQL 5.7.3 以及之前的版本中,
eq_range_index_dive_limit 的默认值为 10,之后的版本默认值为 200。所以如果
大家采用的是 5.7.3 以及之前的版本的话,很容易采用索引统计数据而不是 index
dive 的方式来计算查询成本。当你的查询中使用到了 IN 查询,但是却实际没有
用到索引,就应该考虑一下是不是由于 eq_range_index_dive_limit 值太小导致的