一.optimizer trance

5.0之前可以使用explain查看优化执行方案

但是我们不知道是根据什么、为什么生成这个执行方案的，这导致我们有些时候无法正确分析某些索引失效情况

在5.6之后，可以通过optimizer trance具体查看其生成的执行方案，这个功能可以让我们方便的查看那优化器生成执行计划的整个过程。

怎么使用？

1. SET optimizer_trace="enabled=on"; //开启功能
2. 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;  //执行一次sql
3. SELECT * FROM information_schema.OPTIMIZER_TRACE\G //查看具体方案

我们可以从具体的执行方案中找到对应使用索引和全表扫描具体会花费多少成本

• 全表扫描：2169.9

• 使用索引idx_order_no的成本为72.61：

• 使用索引idx_expire_time的成本为47.81：

mysql会选取成本最少的，也就是我们最终的执行方案

但是这些成本怎么来的呢？搞明白了这些成本的由来，就不会再有诸如“为什么MySQL一 定要全文扫描，不用索引呢？为什么MySQL要用A索引不用B索引之类的疑问？”了，因为 以上的答案都可以用成本分析来解答。

二.什么是成本

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、对比各种执行方案的代价，找出成本最低的那一个

四.优化器分析实战

站在优化器角度来看sql语句

①这个sql可能会使用到哪些索引

MySQL把一个查询中可能使用到的索引称之为possible keys。 我们分析一下上边查询中涉及到的几个搜索条件：

order_no IN ('DD00_6S', 'DD00_9S', 'DD00_10S') ，这个搜索条件可以使用二级索引 idx_order_no。

expire_time> '2021-03-22 18:28:28' AND expire_time<= '2021-03-22 18:35:09'， 这个搜索条件可以使用二级索引idx_expire_time。

insert_time> expire_time，这个搜索条件的索引列由于没有和常数比较，所以并不能 使用到索引。

order_note LIKE '%hello%'，order_note即使有索引，但是通过LIKE操作符和以通配符 开头的字符串做比较，不可以适用索引。

order_status = 0，由于该列上只有联合索引，而且不符合最左前缀原则，所以不会用 到索引。

综上所述，上边的查询语句可能用到的索引，也就是possible keys只有 idx_order_no,idx_expire_time。

通过工具查看是否分析正确：

②计算全表扫描的代价

全表扫描的意思就是把聚簇索引中的记录都依次和给定的搜 索条件做一下比较，把符合搜索条件的记录加入到结果集，所以需要将聚簇索引对应的 页面加载到内存中，然后再检测记录是否符合搜索条件。由于查询成本=I/O成本+CPU成 本，所以计算全表扫描的代价需要两个信息：

聚簇索引占用的页面数

该表中的记录数

怎么查看这个数据呢，其实mysql已经帮助我们维护了这两个数据

SHOW TABLE STATUS LIKE 'order_exp'\G

Rows

本选项表示表中的记录条数。对于使用MyISAM存储引擎的表来说，该值是准确的，对于 使用InnoDB存储引擎的表来说，该值是一个估计值。从查询结果我们也可以看出来，由 于我们的order_exp表是使用InnoDB存储引擎的，所以虽然实际上表中有10567条记录， 但是SHOW TABLE STATUS显示的Rows值只有10354条记录。

Data_length

本选项表示表占用的存储空间字节数。使用MyISAM存储引擎的表来说，该值就是数据文 件的大小，对于使用InnoDB存储引擎的表来说，该值就相当于聚簇索引占用的存储空间 大小，也就是说可以这样计算该值的大小：Data_length = 聚簇索引的页面数量 x 每个页面的大小 我们的order_exp使用默认16KB的页面大小，而上边查询结果显示Data_length的值是 1589248，所以我们可以反向来推导出聚簇索引的页面数量：

聚簇索引的页面数量 = 1589248 ÷ 16 ÷ 1024 = 97 我们现在已经得到了聚簇索引占用的页面数量以及该表记录数的估计值，所以就可以计 算全表扫描成本了。

计算过程：

• I/O成本：

97 x 1.0 + 1.1 = 98.1 97指的是聚簇索引占用的页面数，1.0指的是加载一个页面的IO成本常数，后边的1.1是 一个微调值。

TIPS：MySQL在真实计算成本时会进行一些微调，这些微调的值是直接硬编码到代码里 的，没有注释而且这些微调的值十分的小，并不影响我们大方向的分析。

• CPU成本

10354x 0.2 + 1.0 = 2071.8 10354指的是统计数据中表的记录数，对于InnoDB存储引擎来说是一个估计值，0.2指的 是访问一条记录所需的CPU成本常数，后边的1.0是一个微调值。

总成本： 98.1 + 2071.8= 2169.9 综上所述，对于order_exp的全表扫描所需的总成本就是2169.9

TIPS：我们前边说过表中的记录其实都存储在聚簇索引对应B+树的叶子节点中，所以只 要我们通过根节点获得了最左边的叶子节点，就可以沿着叶子节点组成的双向链表把所 有记录都查看一遍。也就是说全表扫描这个过程其实有的B+树非叶子节点是不需要访问的，但是MySQL在计算 全表扫描成本时直接使用聚簇索引占用的页面数作为计算I/O成本的依据，是不区分非叶 子节点和叶子节点的。

上面说的是全表扫描，那么根据索引呢？

③计算走索引成本

使用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' )。 使用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）中对应的目录项记录之间隔着几条记录。在一个页面 中统计两条记录之间有几条记录的成本就很小了。

不过还有问题，如果页b和页c之间的页面实在太多，以至于页b和页c对应的目录项记录 都不在一个父页面中怎么办？既然是树，那就继续递归，之前我们说过一个B+树有4层高 已经很了不得了，所以这个统计过程也不是很耗费性能。 知道了如何统计二级索引某个范围区间的记录数之后，就需要回到现实问题中来，MySQL 根据上述算法测得idx_expire_time在区间('2021-03-22 18:28:28' ，'2021-03-22 18:35:09')之间大约有39条记录。

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是微调。

3、根据这些记录里的主键值到聚簇索引中做回表操作

MySQL评估回表操作的I/O成本依旧很简单粗暴，他们认为每次回表操作都相当于访问一 个页面，也就是说二级索引范围区间有多少记录，就需要进行多少次回表操作，也就是 需要进行多少次页面I/O。我们上边统计了使用idx_expire_time二级索引执行查询时， 预计有39 条二级索引记录需要进行回表操作，所以回表操作带来的I/O成本就是：

39 x 1.0 = 39 .0

其中39 是预计的二级索引记录数，1.0是一个页面的I/O成本常数。

4、回表操作后得到的完整用户记录，然后再检测其他搜索条件是否成立

回表操作的本质就是通过二级索引记录的主键值到聚簇索引中找到完整的用户记录，然 后再检测除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

④计算索引成本2

使用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执行查询的成本就如下所示：

I/O成本： 3.0 + 58 x 1.0 = 61.0 (范围区间的数量 + 预估的二级索引记录条数)

CPU成本： 58 x 0.2 + 58 x 0.2 + 0.01 = 23.21 （读取二级索引记录的成本 + 读取并检测回表 后聚簇索引记录的成本）

综上所述，使用idx_order_no执行查询的总成本就是： 61.0 + 23.21 = 84.21 是否有可能使用索引合并（Index Merge） 本例中SQL语句不满足索引合并的条件，所以并不会使用索引合并。而且MySQL查询优化 器计算索引合并成本的算法也比较麻烦，我们不去了解。

⑤对比

对比各种方案，找出成本最低的那一个

下边把执行本例中的查询的各种可执行方案以及它们对应的成本列出来： 全表扫描的成本：2169.9 使用idx_expire_time的成本：55.61 使用idx_order_no的成本：84.21 很显然，使用idx_expire_time的成本最低，所以当然选择idx_expire_time来执行查 询。来和Tracer中的比较一下：

请注意：

1、在MySQL的实际计算中，在和全文扫描比较成本时，使用索引的成本会去除读取并检 测回表后聚簇索引记录的成本，也就是说，我们通过MySQL看到的成本将会是： idx_expire_time为47.81(55.61-7.8)，idx_order_no为72.61(84.21-11.6)。但是MySQL 比较完成本后，会再计算一次使用索引的成本，此时就会加上前面去除的成本，也就是 我们计算出来的值。

2、MySQL的源码中对成本的计算实际要更复杂，但是基本思想和算法是没错的。