第16章查询优化的百科全书-Explain详解（下）

执行计划输出中各列详解 #

本章紧接着上一节的内容，继续介绍EXPLAIN语句输出的各个列的意思。

Extra #

顾名思义，Extra列是用来说明一些额外信息的，我们可以通过这些额外信息来更准确的理解MySQL到底将如何执行给定的查询语句。MySQL提供的额外信息有好几十个，我们就不一个一个介绍了（都介绍了感觉我们的文章就跟文档差不多了～），所以我们只挑一些平时常见的或者比较重要的额外信息介绍给大家。

No tables used

Impossible WHERE

No matching min/max row

当查询列表处有MIN或者MAX聚集函数，但是并没有符合WHERE子句中的搜索条件的记录时，将会提示该额外信息，比方说：

Using index

Using index condition

有些搜索条件中虽然出现了索引列，但却不能使用到索引，比如下面这个查询：

SELECT * FROM s1 WHERE key1 > 'z' AND key1 LIKE '%a'; 其中的key1 > 'z'可以使用到索引，但是key1 LIKE '%a'却无法使用到索引，在以前版本的MySQL中，是按照下面步骤来执行这个查询的： - 先根据key1 > 'z'这个条件，从二级索引idx_key1中获取到对应的二级索引记录。 - 根据上一步骤得到的二级索引记录中的主键值进行回表，找到完整的用户记录再检测该记录是否符合key1 LIKE '%a'这个条件，将符合条件的记录加入到最后的结果集。

但是虽然key1 LIKE '%a'不能组成范围区间参与range访问方法的执行，但这个条件毕竟只涉及到了key1列，所以设计MySQL的大佬把上面的步骤改进了一下： - 先根据key1 > 'z'这个条件，定位到二级索引idx_key1中对应的二级索引记录。 - 对于指定的二级索引记录，先不着急回表，而是先检测一下该记录是否满足key1 LIKE '%a'这个条件，如果这个条件不满足，则该二级索引记录压根儿就没必要回表。 - 对于满足key1 LIKE '%a'这个条件的二级索引记录执行回表操作。

我们说回表操作其实是一个随机IO，比较耗时，所以上述修改虽然只改进了一点点，但是可以省去好多回表操作的成本。设计MySQL的大佬们把他们的这个改进称之为索引条件下推（英文名：Index Condition Pushdown）。

如果在查询语句的执行过程中将要使用索引条件下推这个特性，在Extra列中将会显示Using index condition，比如这样：

Using where

当我们使用全表扫描来执行对某个表的查询，并且该语句的WHERE子句中有针对该表的搜索条件时，在Extra列中会提示上述额外信息。比如下面这个查询：

Using join buffer (Block Nested Loop)

在连接查询执行过程中，当被驱动表不能有效的利用索引加快访问速度，MySQL一般会为其分配一块名叫join buffer的内存块来加快查询速度，也就是我们所讲的基于块的嵌套循环算法，比如下面这个查询语句：

可以在对s2表的执行计划的Extra列显示了两个提示：

Using join buffer (Block Nested Loop)：这是因为对表s2的访问不能有效利用索引，只好退而求其次，使用join buffer来减少对s2表的访问次数，从而提高性能。

Using where：可以看到查询语句中有一个s1.common_field = s2.common_field条件，因为s1是驱动表，s2是被驱动表，所以在访问s2表时，s1.common_field的值已经确定下来了，所以实际上查询s2表的条件就是s2.common_field = 一个常数，所以提示了Using where额外信息。

Not exists

当我们使用左（外）连接时，如果WHERE子句中包含要求被驱动表的某个列等于NULL值的搜索条件，而且那个列又是不允许存储NULL值的，那么在该表的执行计划的Extra列就会提示Not exists额外信息，比如这样：

Using intersect(...)、Using union(...)和Using sort_union(...)

如果执行计划的Extra列出现了Using intersect(...)提示，说明准备使用Intersect索引合并的方式执行查询，括号中的...表示需要进行索引合并的索引名称；如果出现了Using union(...)提示，说明准备使用Union索引合并的方式执行查询；出现了Using sort_union(...)提示，说明准备使用Sort-Union索引合并的方式执行查询。比如这个查询的执行计划：

小贴士：剩下两种类型的索引合并的Extra列信息就不一一举例子了，自己写个查询看看呗～

Zero limit

当我们的LIMIT子句的参数为0时，表示压根儿不打算从表中读出任何记录，将会提示该额外信息，比如这样：

Using filesort

Using temporary

在许多查询的执行过程中，MySQL可能会借助临时表来完成一些功能，比如去重、排序之类的，比如我们在执行许多包含DISTINCT、GROUP BY、UNION等子句的查询过程中，如果不能有效利用索引来完成查询，MySQL很有可能寻求通过建立内部的临时表来执行查询。如果查询中使用到了内部的临时表，在执行计划的Extra列将会显示Using temporary提示，比方说这样：

Start temporary, End temporary

我们前面介绍子查询的时候说过，查询优化器会优先尝试将IN子查询转换成semi-join，而semi-join又有好多种执行策略，当执行策略为DuplicateWeedout时，也就是通过建立临时表来实现为外层查询中的记录进行去重操作时，驱动表查询执行计划的Extra列将显示Start temporary提示，被驱动表查询执行计划的Extra列将显示End temporary提示，就是这样：

LooseScan

在将In子查询转为semi-join时，如果采用的是LooseScan执行策略，则在驱动表执行计划的Extra列就是显示LooseScan提示，比如这样：

FirstMatch(tbl_name)

Json格式的执行计划 #

我们上面介绍的EXPLAIN语句输出中缺少了一个衡量执行计划好坏的重要属性 —— 成本。不过设计MySQL的大佬贴心的为我们提供了一种查看某个执行计划花费的成本的方式：

在EXPLAIN单词和真正的查询语句中间加上FORMAT=JSON。

这样我们就可以得到一个json格式的执行计划，里边儿包含该计划花费的成本，比如这样： ``` mysql> EXPLAIN FORMAT=JSON SELECT * FROM s1 INNER JOIN s2 ON s1.key1 = s2.key2 WHERE s1.common_field = ‘a’\G *************************** 1. row ***************************

EXPLAIN: { “query_block”: { “select_id”: 1, # 整个查询语句只有1个SELECT关键字，该关键字对应的id号为1 “cost_info”: { “query_cost”: “3197.16” # 整个查询的执行成本预计为3197.16 }, “nested_loop”: [ # 几个表之间采用嵌套循环连接算法执行

# 以下是参与嵌套循环连接算法的各个表的信息
  {
    "table": {
      "table_name": "s1",   # s1表是驱动表
      "access_type": "ALL",     # 访问方法为ALL，意味着使用全表扫描访问
      "possible_keys": [    # 可能使用的索引
        "idx_key1"
      ],
      "rows_examined_per_scan": 9688,   # 查询一次s1表大致需要扫描9688条记录
      "rows_produced_per_join": 968,    # 驱动表s1的扇出是968
      "filtered": "10.00",  # condition filtering代表的百分比
      "cost_info": {
        "read_cost": "1840.84",     # 稍后解释
        "eval_cost": "193.76",      # 稍后解释
        "prefix_cost": "2034.60",   # 单次查询s1表总共的成本
        "data_read_per_join": "1M"  # 读取的数据量
      },
      "used_columns": [     # 执行查询中涉及到的列
        "id",
        "key1",
        "key2",
        "key3",
        "key_part1",
        "key_part2",
        "key_part3",
        "common_field"
      ],

      # 对s1表访问时针对单表查询的条件
      "attached_condition": "((`xiaohaizi`.`s1`.`common_field` = 'a') and (`xiaohaizi`.`s1`.`key1` is not null))"
    }
  },
  {
    "table": {
      "table_name": "s2",   # s2表是被驱动表
      "access_type": "ref",     # 访问方法为ref，意味着使用索引等值匹配的方式访问
      "possible_keys": [    # 可能使用的索引
        "idx_key2"
      ],
      "key": "idx_key2",    # 实际使用的索引
      "used_key_parts": [   # 使用到的索引列
        "key2"
      ],
      "key_length": "5",    # key_len
      "ref": [      # 与key2列进行等值匹配的对象
        "xiaohaizi.s1.key1"
      ],
      "rows_examined_per_scan": 1,  # 查询一次s2表大致需要扫描1条记录
      "rows_produced_per_join": 968,    # 被驱动表s2的扇出是968（由于后边没有多余的表进行连接，所以这个值也没什么用）
      "filtered": "100.00",     # condition filtering代表的百分比

      # s2表使用索引进行查询的搜索条件
      "index_condition": "(`xiaohaizi`.`s1`.`key1` = `xiaohaizi`.`s2`.`key2`)",
      "cost_info": {
        "read_cost": "968.80",      # 稍后解释
        "eval_cost": "193.76",      # 稍后解释
        "prefix_cost": "3197.16",   # 单次查询s1、多次查询s2表总共的成本
        "data_read_per_join": "1M"  # 读取的数据量
      },
      "used_columns": [     # 执行查询中涉及到的列
        "id",
        "key1",
        "key2",
        "key3",
        "key_part1",
        "key_part2",
        "key_part3",
        "common_field"
      ]
    }
  }
]

} } 1 row in set, 2 warnings (0.00 sec) 我们使用#后边跟随注释的形式为大家解释了EXPLAIN FORMAT=JSON语句的输出内容，但是大家可能有疑问“cost_info”里边的成本看着怪怪的，它们是怎么计算出来的？先看s1表的“cost_info”部分： “cost_info”: { “read_cost”: “1840.84”, “eval_cost”: “193.76”, “prefix_cost”: “2034.60”, “data_read_per_join”: “1M” } ```

read_cost是由下面这两部分组成的：

+ `IO`成本 
+ 检测`rows × (1 - filter)`条记录的`CPU`成本

小贴士：rows和filter都是我们前面介绍执行计划的输出列，在JSON格式的执行计划中，rows相当于rows_examined_per_scan，filtered名称不变。

eval_cost是这样计算的：

检测 rows × filter条记录的成本。

prefix_cost就是单独查询s1表的成本，也就是：

read_cost + eval_cost

data_read_per_join表示在此次查询中需要读取的数据量，我们就不多介绍这个了。

小贴士：大家其实没必要关注MySQL为什么使用这么古怪的方式计算出read_cost和eval_cost，关注prefix_cost是查询s1表的成本就好了。 对于s2表的"cost_info"部分是这样的： "cost_info": { "read_cost": "968.80", "eval_cost": "193.76", "prefix_cost": "3197.16", "data_read_per_join": "1M" } 由于s2表是被驱动表，所以可能被读取多次，这里的read_cost和eval_cost是访问多次s2表后累加起来的值，大家主要关注里边儿的prefix_cost的值代表的是整个连接查询预计的成本，也就是单次查询s1表和多次查询s2表后的成本的和，也就是： 968.80 + 193.76 + 2034.60 = 3197.16

Extented EXPLAIN #

mysql> SHOW WARNINGS\G *************************** 1. row ************************** Level: Note Code: 1003 Message: / select#1 */ select xiaohaizi.s1.key1 AS key1,xiaohaizi.s2.key1 AS key1 from xiaohaizi.s1 join xiaohaizi.s2 where ( $`xiaohaizi`.`s1`.`key1` = `xiaohaizi`.`s2`.`key1`) and (`xiaohaizi`.`s2`.`common_field` is not null)$ 1 row in set (0.00 sec) ``` 大家可以看到SHOW WARNINGS展示出来的信息有三个字段，分别是Level、Code、Message。我们最常见的就是Code为1003的信息，当Code值为1003时，Message字段展示的信息类似于查询优化器将我们的查询语句重写后的语句。比如我们上面的查询本来是一个左（外）连接查询，但是有一个s2.common_field IS NOT NULL的条件，着就会导致查询优化器把左（外）连接查询优化为内连接查询，从SHOW WARNINGS的Message字段也可以看出来，原本的LEFT JOIN已经变成了JOIN。

但是大家一定要注意，我们说Message字段展示的信息类似于查询优化器将我们的查询语句重写后的语句，并不是等价于，也就是说Message字段展示的信息并不是标准的查询语句，在很多情况下并不能直接拿到黑框框中运行，它只能作为帮助我们理解查MySQL将如何执行查询语句的一个参考依据而已。