《MySQL是怎样运行的 —— 从跟上理解MySQL》—— 第十二章

一、MySQL的查询成本

MySQL执行一个查询可以有不同的执行方案，它会选择其中成本最低，或者说代价最低的那种方案去真正的执行查询。

在MySQL中一条查询语句的执行成本是由下面这两个方面组成的：

I/O成本：表是通过存储引擎将数据和索引都存储到磁盘上的，当想查询表中的记录时，需要先把数据或者索引加载到内存中然后再操作。这个从磁盘到内存这个加载的过程损耗的时间称之为I/O成本。
CPU成本：读取以及检测记录是否满足对应的搜索条件、对结果集进行排序等这些操作损耗的时间称之为CPU成本。

对于InnoDB存储引擎来说，页是磁盘和内存之间交互的基本单位，MySQL规定读取一个页面花费的成本默认是1.0，读取以及检测一条记录是否符合搜索条件的成本默认是0.2。1.0、0.2这些数字称之为成本常数。

⚠️注意：不管读取记录时需不需要检测是否满足搜索条件，其成本都算是0.2。

二、单表查询的成本

示例表（内有10000条数据）：

CREATE TABLE single_table (
    id INT NOT NULL AUTO_INCREMENT,
    key1 VARCHAR(100),
    key2 INT,
    key3 VARCHAR(100),
    key_part1 VARCHAR(100),
    key_part2 VARCHAR(100),
    key_part3 VARCHAR(100),
    common_field VARCHAR(100),
    PRIMARY KEY (id),
    KEY idx_key1 (key1),
    UNIQUE KEY idx_key2 (key2),
    KEY idx_key3 (key3),
    KEY idx_key_part(key_part1, key_part2, key_part3)
) Engine=InnoDB CHARSET=utf8;

2.1 基于成本的优化步骤

在一条单表查询语句真正执行之前，MySQL的查询优化器会找出执行该语句所有可能使用的方案，对比之后找出成本最低的方案，这个成本最低的方案就是执行计划，之后才会调用存储引擎提供的接口真正的执行查询，这个过程总结一下就是这样：

根据搜索条件，找出所有可能使用的索引
计算全表扫描的代价
计算使用不同索引执行查询的代价
对比各种执行方案的代价，找出成本最低的那一个

示例：

SELECT * FROM single_table WHERE 
    key1 IN ('a', 'b', 'c') AND 
    key2 > 10 AND key2 < 1000 AND 
    key3 > key2 AND 
    key_part1 LIKE '%hello%' AND
    common_field = '123';

2.1.1 根据搜索条件，找出所有可能使用的索引

对于B+树索引来说，只要索引列和常数使用=、<=>、IN、NOT IN、IS NULL、IS NOT NULL、>、<、>=、<=、BETWEEN、!=（不等于也可以写成<>）或者LIKE操作符连接起来，就可以产生一个所谓的范围区间（LIKE匹配字符串前缀也行），也就是说这些搜索条件都可能使用到索引，MySQL把一个查询中可能使用到的索引称之为possible keys。

分析一下上面查询中涉及到的几个搜索条件：

key1 IN ('a', 'b', 'c')，这个搜索条件可以使用二级索引idx_key1。
key2 > 10 AND key2 < 1000，这个搜索条件可以使用二级索引idx_key2。
key3 > key2，这个搜索条件的索引列由于没有和常数比较，所以并不能使用到索引。
key_part1 LIKE '%hello%'，key_part1通过LIKE操作符和以通配符开头的字符串做比较，不可以适用索引。
common_field = '123'，由于该列上没有索引，所以不会用到索引。

综上所述，上面的查询语句可能用到的索引：possible keys只有idx_key1和idx_key2。

2.1.2 计算全表扫描的代价

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

聚簇索引占用的页面数
该表中的记录数

MySQL中为每个表维护了一系列的统计信息，从这些统计信息中可以得到这些信息。查看表的统计信息的语句SHOW TABLE STATUS，如果要看指定的某个表的统计信息，在该语句后加对应的LIKE语句即可。

mysql> SHOW TABLE STATUS LIKE 'single_table'\G
*************************** 1. row ***************************
           Name: single_table
         Engine: InnoDB
        Version: 10
     Row_format: Dynamic
           Rows: 9693
 Avg_row_length: 163
    Data_length: 1589248
Max_data_length: 0
   Index_length: 2752512
      Data_free: 4194304
 Auto_increment: 10001
    Create_time: 2018-12-10 13:37:23
    Update_time: 2018-12-10 13:38:03
     Check_time: NULL
      Collation: utf8_general_ci
       Checksum: NULL
 Create_options:
        Comment:
1 row in set (0.01 sec)

虽然出现了很多统计选项，但目前只关心两个：

Rows：表示表中的记录条数。对于使用MyISAM存储引擎的表来说，该值是准确的，对于使用InnoDB存储引擎的表来说，该值是一个估计值。

从查询结果也可以看出来，由于single_table表是使用InnoDB存储引擎的，所以虽然实际上表中有10000条记录，但是SHOW TABLE STATUS显示的Rows值只有9693条记录。
Data_length：表示表占用的存储空间字节数。使用MyISAM存储引擎的表来说，该值就是数据文件的大小，对于使用InnoDB存储引擎的表来说，该值就相当于聚簇索引占用的存储空间大小，也就是说可以这样计算该值的大小：Data_length = 聚簇索引的页面数量 x 每个页面的大小

single_table使用默认16KB的页面大小，而上面查询结果显示Data_length的值是1589248，所以可以反向来推导出聚簇索引的页面数量：聚簇索引的页面数量 = 1589248 ÷ 16 ÷ 1024 = 97

现在已经得到了聚簇索引占用的页面数量以及该表记录数的估计值，所以就可以计算全表扫描成本了，但是MySQL在真实计算成本时会进行一些微调，这些微调的值是直接硬编码到代码里的，不需要纠结这些微调值。

全表扫描成本的计算过程：

I/O成本：97 x 1.0 + 1.1 = 98.1

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

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

综上所述，对于single_table的全表扫描所需的总成本就是2037.7

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

2.1.3 计算使用不同索引执行查询的代价

从第1步分析得到上述查询可能使用到idx_key1和idx_key2这两个索引，此处需要分别分析单独使用这些索引执行查询的成本，最后还要分析是否可能使用到索引合并。

⚠️注意：MySQL查询优化器先分析使用唯一二级索引的成本，再分析使用普通索引的成本。

使用idx_key2执行查询的成本分析

idx_key2对应的搜索条件是：key2 > 10 AND key2 < 1000，也就是说对应的范围区间就是：(10, 1000)，使用idx_key2搜索的示意图：

对于使用二级索引 + 回表方式的查询，MySQL计算这种查询的成本依赖两个方面的数据：

范围区间数量：不论某个范围区间的二级索引到底占用了多少页面，查询优化器粗暴的认为读取索引的一个范围区间的I/O成本和读取一个页面是相同的。

本例中使用idx_key2的范围区间只有一个(10, 1000)，所以相当于访问这个范围区间的二级索引付出的I/O成本就是：1 x 1.0 = 1.0
需要回表的记录数：优化器需要计算二级索引的某个范围区间到底包含多少条记录。

对于本例来说就是要计算idx_key2在(10, 1000)这个范围区间中包含多少二级索引记录，计算过程：
- 步骤1：先根据key2 > 10这个条件访问一下idx_key2对应的B+树索引，找到满足key2 > 10这个条件的第一条记录，这条记录称之为区间最左记录。在B+数树中定位一条记录的过程是贼快的，是常数级别的，所以这个过程的性能消耗是可以忽略不计的。
- 步骤2：然后再根据key2 < 1000这个条件继续从idx_key2对应的B+树索引中找出第一条满足这个条件的记录，这条记录称之为区间最右记录，这个过程的性能消耗也可以忽略不计的。
- 步骤3：如果区间最左记录和区间最右记录相隔不太远（在MySQL 5.7.21这个版本中，只要相隔不大于10个页面即可），那就可以精确统计出满足key2 > 10 AND key2 < 1000条件的二级索引记录条数。否则只沿着区间最左记录向右读10个页面，计算平均每个页面中包含多少记录，然后用这个平均值乘以区间最左记录和区间最右记录之间的页面数量就可以了。

问题：怎么估计区间最左记录和区间最右记录之间有多少个页面呢？

解决这个问题还得回到B+树索引的结构中来：

如图，假设区间最左记录在页b中，区间最右记录在页c中，那么想计算区间最左记录和区间最右记录之间的页面数量就相当于计算页b和页c之间有多少页面，而每一条目录项记录都对应一个数据页，所以计算页b和页c之间有多少页面就相当于计算它们父节点（也就是页a）中对应的目录项记录之间隔着几条记录。在一个页面中统计两条记录之间有几条记录的成本就很小了。

问题：如果页b和页c之间的页面实在太多，以至于页b和页c对应的目录项记录都不在一个页面中该如何解决？

继续递归，也就是再统计页b和页c对应的目录项记录所在页之间有多少个页面。一个B+树有4层高数据量就已经很恐怖了，所以这个统计过程也不是很耗费性能。

根据上述算法测得idx_key2在区间(10, 1000)之间大约有95条记录。读取这95条二级索引记录需要付出的CPU成本就是：95 x 0.2 + 0.01 = 19.01。（其中95是需要读取的二级索引记录条数，0.2是读取一条记录成本常数，0.01是微调）

在通过二级索引获取到记录之后，还需要干两件事儿：

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

MySQL评估回表操作的I/O成本依旧很简单粗暴，它认为每次回表操作都相当于访问一个页面，也就是说二级索引范围区间有多少记录，就需要进行多少次回表操作，也就是需要进行多少次页面I/O。

上面统计了使用idx_key2二级索引执行查询时，预计有95条二级索引记录需要进行回表操作，所以回表操作带来的I/O成本就是：95 x 1.0 = 95.0（其中95是预计的二级索引记录数，1.0是一个页面的I/O成本常数。）
回表操作后得到的完整用户记录，然后再检测其他搜索条件是否成立

回表操作的本质就是通过二级索引记录的主键值到聚簇索引中找到完整的用户记录，然后再检测除key2 > 10 AND key2 < 1000这个搜索条件以外的搜索条件是否成立。

因为通过范围区间获取到二级索引记录共95条，也就对应着聚簇索引中95条完整的用户记录，读取并检测这些完整的用户记录是否符合其余的搜索条件的CPU成本：

MySQL只计算这个查找过程所需的I/O成本，也就是上一步骤中得到的95.0，在内存中的定位完整用户记录的过程的成本是忽略不计的。在定位到这些完整的用户记录后，需要检测除key2 > 10 AND key2 < 1000这个搜索条件以外的搜索条件是否成立，这个比较过程花费的CPU成本就是：95 x 0.2 = 19.0（其中95是待检测记录的条数，0.2是检测一条记录是否符合给定的搜索条件的成本常数。）

所以本例中使用idx_key2执行查询的成本就如下所示：

I/O成本：1.0 + 95 x 1.0 = 96.0 (范围区间的数量 + 预估的二级索引记录条数)
CPU成本：95 x 0.2 + 0.01 + 95 x 0.2 = 38.01 （读取二级索引记录的成本 + 读取并检测回表后聚簇索引记录的成本）

综上所述，使用idx_key2执行查询的总成本就是：96.0 + 38.01 = 134.01

使用idx_key1执行查询的成本分析：

idx_key1对应的搜索条件是：key1 IN ('a', 'b', 'c')，也就是说相当于3个单点区间：

['a', 'a']
['b', 'b']
['c', 'c']

使用idx_key1搜索的示意图如下：

与使用idx_key2的情况类似，也是需要计算使用idx_key1时需要访问的范围区间数量以及需要回表的记录数：

范围区间数量：使用idx_key1执行查询时很显然有3个单点区间，所以访问这3个范围区间的二级索引付出的I/O成本就是：3 x 1.0 = 3.0
需要回表的记录数

由于使用idx_key1时有3个单点区间，所以每个单点区间都需要查找一遍对应的二级索引记录数：
- 查找单点区间['a', 'a']对应的二级索引记录数
  
  计算单点区间对应的二级索引记录数和计算连续范围区间对应的二级索引记录数是一样的，都是先计算区间最左记录和区间最右记录，然后再计算它们之间的记录数，具体算法上面都介绍过了，就不赘述了。最后计算得到单点区间['a', 'a']对应的二级索引记录数是：35。
- 查找单点区间['b', 'b']对应的二级索引记录数
  
  与上同理，计算得到本单点区间对应的记录数是：44。
- 查找单点区间['c', 'c']对应的二级索引记录数
  
  与上同理，计算得到本单点区间对应的记录数是：39。

所以，这三个单点区间总共需要回表的记录数就是：35 + 44 + 39 = 118

读取这些二级索引记录的CPU成本就是：118 x 0.2 + 0.01 = 23.61

得到总共需要回表的记录数之后，就要考虑：

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

所需的I/O成本就是：118 x 1.0 = 118.0
回表操作后得到的完整用户记录，然后再比较其他搜索条件是否成立

此步骤对应的CPU成本就是：118 x 0.2 = 23.6

所以本例中使用idx_key1执行查询的成本就如下所示：

I/O成本：3.0 + 118 x 1.0 = 121.0 (范围区间的数量 + 预估的二级索引记录条数)
CPU成本：118 x 0.2 + 0.01 + 118 x 0.2 = 47.21 （读取二级索引记录的成本 + 读取并检测回表后聚簇索引记录的成本）

综上所述，使用idx_key1执行查询的总成本就是：121.0 + 47.21 = 168.21

2.1.4 对比各种执行方案的代价，找出成本最低的那一个

执行本例中的查询的各种可执行方案以及它们对应的成本：

全表扫描的成本：2037.7
使用idx_key2的成本：134.01
使用idx_key1的成本：168.21

很显然，使用idx_key2的成本最低，所以当然选择idx_key2来执行查询喽。

2.2 基于索引统计数据的成本计算

有时候使用索引执行查询时会有许多单点区间，比如使用IN语句就很容易产生非常多的单点区间。

【🌰栗子】

SELECT * FROM single_table WHERE key1 IN ('aa1', 'aa2', 'aa3', ... , 'zzz');

很显然，这个查询可能使用到的索引就是idx_key1，由于这个索引并不是唯一二级索引，所以并不能确定一个单点区间对应的二级索引记录的条数有多少，需要去计算。计算方式就是先获取索引对应的B+树的区间最左记录和区间最右记录，然后再计算这两条记录之间有多少记录（记录条数少的时候可以做到精确计算，多的时候只能估算）。MySQL把这种通过直接访问索引对应的B+树来计算某个范围区间对应的索引记录条数的方式称之为index dive。

有少数几个单点区间的话，使用index dive的方式去计算这些单点区间对应的记录数也不是什么问题，但是太多的话，这性能损耗太大，甚至计算这些单点区间对应的索引记录条数的成本比直接全表扫描的成本都大了。MySQL提供了一个系统变量eq_range_index_dive_limit，在MySQL 5.7.21中这个系统变量的默认值：

mysql> SHOW VARIABLES LIKE '%dive%';
+---------------------------+-------+
| Variable_name             | Value |
+---------------------------+-------+
| eq_range_index_dive_limit | 200   |
+---------------------------+-------+
1 row in set (0.08 sec)

也就是说如果IN语句中的参数个数小于200个的话，将使用index dive的方式计算各个单点区间对应的记录条数，如果大于或等于200个的话，可就不能使用index dive了，要使用索引统计数据来进行估算。

MySQL会为表中的每一个索引维护一份统计数据，查看某个表中索引的统计数据可以使用SHOW INDEX FROM 表名的语法，比如查看一下single_table的各个索引的统计数据：

mysql> SHOW INDEX FROM single_table;
+--------------+------------+--------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table        | Non_unique | Key_name     | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+--------------+------------+--------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| single_table |          0 | PRIMARY      |            1 | id          | A         |       9693  |     NULL | NULL   |      | BTREE      |         |               |
| single_table |          0 | idx_key2     |            1 | key2        | A         |       9693  |     NULL | NULL   | YES  | BTREE      |         |               |
| single_table |          1 | idx_key1     |            1 | key1        | A         |        968 |     NULL | NULL   | YES  | BTREE      |         |               |
| single_table |          1 | idx_key3     |            1 | key3        | A         |        799 |     NULL | NULL   | YES  | BTREE      |         |               |
| single_table |          1 | idx_key_part |            1 | key_part1   | A         |        9673 |     NULL | NULL   | YES  | BTREE      |         |               |
| single_table |          1 | idx_key_part |            2 | key_part2   | A         |        9999 |     NULL | NULL   | YES  | BTREE      |         |               |
| single_table |          1 | idx_key_part |            3 | key_part3   | A         |       10000 |     NULL | NULL   | YES  | BTREE      |         |               |
+--------------+------------+--------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
7 rows in set (0.01 sec)

属性说明：

属性名	描述
`Table`	索引所属表的名称。
`Non_unique`	索引列的值是否是唯一的，聚簇索引和唯一二级索引的该列值为`0`，普通二级索引该列值为`1`。
`Key_name`	索引的名称。
`Seq_in_index`	索引列在索引中的位置，从1开始计数。比如对于联合索引`idx_key_part`，来说，`key_part1`、`key_part2`和`key_part3`对应的位置分别是1、2、3。
`Column_name`	索引列的名称。
`Collation`	索引列中的值是按照何种排序方式存放的，值为`A`时代表升序存放，为`NULL`时代表降序存放。
`Cardinality`	索引列中不重复值的数量。
`Sub_part`	对于存储字符串或者字节串的列来说，有时候我们只想对这些串的前`n`个字符或字节建立索引，这个属性表示的就是那个`n`值。如果对完整的列建立索引的话，该属性的值就是`NULL`。
`Packed`	索引列如何被压缩，`NULL`值表示未被压缩。这个属性暂时不了解，可以先忽略掉。
`Null`	该索引列是否允许存储`NULL`值。
`Index_type`	使用索引的类型，最常见的就是`BTREE`，其实也就是`B+`树索引。
`Comment`	索引列注释信息。
`Index_comment`	索引注释信息。

Cardinality直译过来就是基数的意思，表示索引列中不重复值的个数。比如对于一个一万行记录的表来说，某个索引列的Cardinality属性是10000，那意味着该列中没有重复的值，如果Cardinality属性是1的话，就意味着该列的值全部是重复的。不过需要注意的是，对于InnoDB存储引擎来说，使用SHOW INDEX语句展示出来的某个索引列的Cardinality属性是一个估计值，并不是精确的。

当IN语句中的参数个数大于或等于系统变量eq_range_index_dive_limit的值的话，就不会使用index dive的方式计算各个单点区间对应的索引记录条数，而是使用索引统计数据，这里所指的索引统计数据指的是这两个值：

使用SHOW TABLE STATUS展示出的Rows值，也就是一个表中有多少条记录。
使用SHOW INDEX语句展示出的Cardinality属性。

结合上一个Rows统计数据，我们可以针对索引列，计算出平均一个值重复多少次：一个值的重复次数 ≈ Rows / Cardinality

以single_table表的idx_key1索引为例，它的Rows值是9693，它对应索引列key1的Cardinality值是968，所以我们可以计算key1列平均单个值的重复次数就是：9693 ÷ 968 ≈ 10（条）

此时再看上面那条查询语句：

SELECT * FROM single_table WHERE key1 IN ('aa1', 'aa2', 'aa3', ... , 'zzz');

假设IN语句中有20000个参数的话，就直接使用统计数据来估算这些参数需要单点区间对应的记录条数了，每个参数大约对应10条记录，所以总共需要回表的记录数就是：20000 x 10 = 200000

使用统计数据来计算单点区间对应的索引记录条数可比index dive的方式简单多了，但是它的致命弱点就是不精确。使用统计数据算出来的查询成本与实际所需的成本可能相差非常大。

⚠️注意：在MySQL 5.7.3以及之前的版本中，eq_range_index_dive_limit的默认值为10，之后的版本默认值为200。5.7.3以及之前的版本的话，很容易采用索引统计数据而不是index dive的方式来计算查询成本。当查询中使用到了IN查询，但是却实际没有用到索引，就应该考虑一下是不是由于 eq_range_index_dive_limit 值太小导致的。

三、连接查询到成本

3.1 条件过滤 (Condition Filtering)

MySQL中连接查询采用的是嵌套循环连接算法，驱动表会被访问一次，被驱动表可能会被访问多次，所以对于两表连接查询来说，它的查询成本由下面两个部分构成：

单次查询驱动表的成本
多次查询被驱动表的成本（具体查询多少次取决于对驱动表查询的结果集中有多少条记录）

对驱动表进行查询后得到的记录条数称为驱动表的扇出(fanout)。很显然驱动表的扇出值越小，对被驱动表的查询次数也就越少，连接查询的总成本也就越低。

当查询优化器想计算整个连接查询所使用的成本时，就需要计算出驱动表的扇出值，有的时候扇出值的计算是很容易的，比如：

查询一：
SELECT * FROM single_table AS s1 INNER JOIN single_table2 AS s2;
假设使用s1表作为驱动表，显然对驱动表的单表查询只能使用全表扫描的方式执行，驱动表的扇出值也很明确，那就是驱动表中有多少记录，扇出值就是多少。
查询二：
SELECT * FROM single_table AS s1 INNER JOIN single_table2 AS s2
WHERE s1.key2 >10 AND s1.key2 < 1000;
假设s1表是驱动表的话，显然对驱动表的单表查询可以使用idx_key2索引执行查询。此时idx_key2的范围区间(10, 1000)中有多少条记录，那么扇出值就是多少。
查询三：
SELECT * FROM single_table AS s1 INNER JOIN single_table2 AS s2
WHERE s1.common_field > 'xyz';
本查询和查询一类似，只不过对于驱动表s1多了一个common_field > 'xyz'的搜索条件。查询优化器又不会真正的去执行查询，所以它只能从全表扫描到数据中猜测这些记录里有多少条记录满足common_field > 'xyz'条件。
查询四：
SELECT * FROM single_table AS s1 INNER JOIN single_table2 AS s2
WHERE s1.key2 > 10 AND s1.key2 < 1000 AND
s1.common_field > 'xyz';
本查询和查询二类似，只不过对于驱动表s1也多了一个common_field > 'xyz'的搜索条件。不过因为本查询可以使用idx_key2索引，所以只需要从符合二级索引范围区间的记录中猜有多少条记录符合common_field > 'xyz'条件.
查询五：
SELECT * FROM single_table AS s1 INNER JOIN single_table2 AS s2
WHERE s1.key2 > 10 AND s1.key2 < 1000 AND
s1.key1 IN ('a', 'b', 'c') AND
s1.common_field > 'xyz';
本查询和查询二类似，不过在驱动表s1选取idx_key2索引执行查询后，优化器需要从符合二级索引范围区间的记录中猜有多少条记录符合下面两个条件：
- key1 IN ('a', 'b', 'c')
- common_field > 'xyz'

=> 结论：

如果使用的是全表扫描的方式执行的单表查询，那么计算驱动表扇出时需要猜满足搜索条件的记录到底有多少条。
如果使用的是索引执行的单表扫描，那么计算驱动表扇出的时候需要猜满足除使用到对应索引的搜索条件外的其他搜索条件的记录有多少条。

MySQL把这个猜的过程称之为condition filtering。当然，这个过程可能会使用到索引，也可能使用到统计数据，也可能就是MySQL的推断（启发式规则heuristic）。

3.2 两表连接到成本分析

连接查询的成本计算公式：连接查询总成本 = 单次访问驱动表的成本 + 驱动表扇出数 x 单次访问被驱动表的成本。

对于左（外）连接和右（外）连接查询来说，它们的驱动表是固定的，所以想要得到最优的查询方案只需要分别为驱动表和被驱动表选择成本最低的访问方法。

可是对于内连接来说，驱动表和被驱动表的位置是可以互换的，所以需要考虑两个方面的问题：

不同的表作为驱动表最终的查询成本可能是不同的，也就是需要考虑最优的表连接顺序。
然后分别为驱动表和被驱动表选择成本最低的访问方法。

连接查询成本占大头的是驱动表扇出数 x 单次访问被驱动表的成本，因此优化重点其实是下面这两个部分：

尽量减少驱动表的扇出
对被驱动表的访问成本尽量低（这一点对于实际书写连接查询语句时十分有用，我们需要尽量在被驱动表的连接列上建立索引，这样就可以使用ref访问方法来降低访问被驱动表的成本了。如果可以，被驱动表的连接列最好是该表的主键或者唯一二级索引列，这样就可以把访问被驱动表的成本降得更低。）

3.4 多表连接的成本分析

对于n表连接的话，则有 n × (n-1) × (n-2) × ··· × 1种连接顺序，就是n的阶乘种连接顺序，也就是n!。

有n个表进行连接，MySQL查询优化器并不是要每一种连接顺序的成本都计算一遍，MySQL减少计算非常多种连接顺序的成本的方法：

提前结束某种顺序的成本评估

MySQL在计算各种链接顺序的成本之前，会维护一个全局的变量，这个变量表示当前最小的连接查询成本。如果在分析某个连接顺序的成本时，该成本已经超过当前最小的连接查询成本，那就不对该连接顺序继续往下分析。
系统变量optimizer_search_depth

为了防止无穷无尽的分析各种连接顺序的成本，MySQL提供optimizer_search_depth系统变量，如果连接表的个数小于该值，那么就继续穷举分析每一种连接顺序的成本，否则只对与optimizer_search_depth值相同数量的表进行穷举分析。显然，该值越大，成本分析的越精确，越容易得到好的执行计划，但是消耗的时间也就越长，否则得到不是很好的执行计划，但可以省掉很多分析连接成本的时间。
根据某些规则不考虑某些连接顺序

即使是有上面两条规则的限制，但是分析多个表不同连接顺序成本花费的时间还是会很长，MySQL提出了一些所谓的启发式规则（就是根据以往经验指定的一些规则），凡是不满足这些规则的连接顺序无需分析，这样可以极大的减少需要分析的连接顺序的数量，但是也可能造成错失最优的执行计划。MySQL提供了一个系统变量optimizer_prune_level来控制到底是不是用这些启发式规则。

四、调节成本常数

MySQL提供了许多成本常数，它们被存储到了mysql数据库：

mysql> SHOW TABLES FROM mysql LIKE '%cost%';
+--------------------------+
| Tables_in_mysql (%cost%) |
+--------------------------+
| engine_cost              |
| server_cost              |
+--------------------------+
2 rows in set (0.00 sec)

4.1 mysql.server_cost表

server_cost表中在server层进行的一些操作对应的成本常数，具体内容如下：

mysql> SELECT * FROM mysql.server_cost;
+------------------------------+------------+---------------------+---------+
| cost_name                    | cost_value | last_update         | comment |
+------------------------------+------------+---------------------+---------+
| disk_temptable_create_cost   |       NULL | 2018-01-20 12:03:21 | NULL    |
| disk_temptable_row_cost      |       NULL | 2018-01-20 12:03:21 | NULL    |
| key_compare_cost             |       NULL | 2018-01-20 12:03:21 | NULL    |
| memory_temptable_create_cost |       NULL | 2018-01-20 12:03:21 | NULL    |
| memory_temptable_row_cost    |       NULL | 2018-01-20 12:03:21 | NULL    |
| row_evaluate_cost            |       NULL | 2018-01-20 12:03:21 | NULL    |
+------------------------------+------------+---------------------+---------+
6 rows in set (0.05 sec)

各个列的解释：

cost_name：表示成本常数的名称。
cost_value：表示成本常数对应的值。如果该列的值为NULL的话，意味着对应的成本常数会采用默认值。
last_update：表示最后更新记录的时间。
comment：注释。

从server_cost中的内容可以看出来，目前在server层的一些操作对应的成本常数有以下几种：

成本常数名称	默认值	描述
`disk_temptable_create_cost`	`40.0`	创建基于磁盘的临时表的成本，如果增大这个值的话会让优化器尽量少的创建基于磁盘的临时表。
`disk_temptable_row_cost`	`1.0`	向基于磁盘的临时表写入或读取一条记录的成本，如果增大这个值的话会让优化器尽量少的创建基于磁盘的临时表。
`key_compare_cost`	`0.1`	两条记录做比较操作的成本，多用在排序操作上，如果增大这个值的话会提升`filesort`的成本，让优化器可能更倾向于使用索引完成排序而不是`filesort`。
`memory_temptable_create_cost`	`2.0`	创建基于内存的临时表的成本，如果增大这个值的话会让优化器尽量少的创建基于内存的临时表。
`memory_temptable_row_cost`	`0.2`	向基于内存的临时表写入或读取一条记录的成本，如果增大这个值的话会让优化器尽量少的创建基于内存的临时表。
`row_evaluate_cost`	`0.2`	这个就是我们之前一直使用的检测一条记录是否符合搜索条件的成本，增大这个值可能让优化器更倾向于使用索引而不是直接全表扫描。

这些成本常数在server_cost中的初始值都是NULL，意味着优化器会使用它们的默认值来计算某个操作的成本。

如果想修改某个成本常数的值的话，需要做两个步骤：

对感兴趣的成本常数做更新操作

比如想把检测一条记录是否符合搜索条件的成本增大到0.4，那么就可以这样写更新语句：
UPDATE mysql.server_cost
SET cost_value = 0.4
WHERE cost_name = 'row_evaluate_cost';
让系统重新加载这个表的值。

使用下面语句即可：
FLUSH OPTIMIZER_COSTS;

修改完某个成本常数后想把它们再改回默认值的话，可以直接把cost_value的值设置为NULL，再使用FLUSH OPTIMIZER_COSTS语句让系统重新加载它就好了。

4.2 mysql.engine_cost表

engine_cost表表中在存储引擎层进行的一些操作对应的成本常数，具体内容如下：

mysql> SELECT * FROM mysql.engine_cost;
+-------------+-------------+------------------------+------------+---------------------+---------+
| engine_name | device_type | cost_name              | cost_value | last_update         | comment |
+-------------+-------------+------------------------+------------+---------------------+---------+
| default     |           0 | io_block_read_cost     |       NULL | 2018-01-20 12:03:21 | NULL    |
| default     |           0 | memory_block_read_cost |       NULL | 2018-01-20 12:03:21 | NULL    |
+-------------+-------------+------------------------+------------+---------------------+---------+
2 rows in set (0.05 sec)

与server_cost相比，engine_cost多了两个列：

engine_name列：指成本常数适用的存储引擎名称。如果该值为default，意味着对应的成本常数适用于所有的存储引擎。
device_type列：指存储引擎使用的设备类型，这主要是为了区分常规的机械硬盘和固态硬盘。

从engine_cost表中的内容可以看出来，目前支持的存储引擎成本常数只有两个：

成本常数名称	默认值	描述
`io_block_read_cost`	`1.0`	从磁盘上读取一个块对应的成本。对于`InnoDB`存储引擎来说，一个`页`就是一个块，不过对于`MyISAM`存储引擎来说，默认是以`4096`字节作为一个块的。增大这个值会加重`I/O`成本，可能让优化器更倾向于选择使用索引执行查询而不是执行全表扫描。
`memory_block_read_cost`	`1.0`	与上一个参数类似，只不过衡量的是从内存中读取一个块对应的成本。

与更新server_cost表中的记录一样，可以通过更新engine_cost表中的记录来更改关于存储引擎的成本常数，也可以通过为engine_cost表插入新记录的方式来添加只针对某种存储引擎的成本常数：

插入针对某个存储引擎的成本常数

比如我们想增大InnoDB存储引擎页面I/O的成本，书写正常的插入语句即可：

INSERT INTO mysql.engine_cost
    VALUES ('InnoDB', 0, 'io_block_read_cost', 2.0,
    CURRENT_TIMESTAMP, 'increase Innodb I/O cost');

让系统重新加载这个表的值。FLUSH OPTIMIZER_COSTS;

youyichannel

重拾MySQL —— MySQL基于成本的优化