MySQL系列—EXPLAIN 介绍

一、EXPLAIN 介绍

为了帮助开发人员根据数据表中现有索引情况，了解自己编写的SQL的执行过程、优化SQL结构，mysql提供了一套分析功能叫做SQL执行计划（explain）。下面我们就为大家介绍一下执行计划功能的使用。

讲解过程中使用的数据表的结构：

# 我们所示例的数据表和SQL语句均是工作在InnoDB数据库引擎下# myuser数据表一共有4个字段，3个索引。# user_name字段上创建了非唯一键非聚簇索引# user_number字段上创建了唯一键非聚簇索引# id字段上是聚簇索引CREATE TABLE `myuser` (  `Id` INT (11) NOT NULL AUTO_INCREMENT,  `user_name` VARCHAR (255) NOT NULL DEFAULT '',  `usersex` INT (9) NOT NULL DEFAULT '0',  `user_number` INT (11) NOT NULL DEFAULT '0',  PRIMARY KEY (`Id`),  UNIQUE KEY `number_index` (`user_number`),  KEY `name_index` (`user_name`))

以上表头的各个字段项目的大致意义如下：

• id：每个被独立执行的操作的标识，表示对象被操作的顺序；ID值大，先被执行；如果相同，执行顺序一般从上到下；
• select_type：数据库引擎将SQL拆分成若干部分的子查询/子操作，每个查询select子句中的查询类型（后文详细讲解）；
• table: 本次子查询所查询的目标数据表。SQL查询语句即使再复杂，一次子查询也只可能最多关联一张数据表；
• partitions：本次查询所涉及的数据表目标分区信息（如果有分区的话）。后文将对分区的概念进行概要说明；
• type：子查询类型，非常重要的性能衡量点。这个字段项可能显示的值包括：“ALL->index->range->ref->eq_ref->const | system->NULL”这些值所表示的查询性能，从左至右依次增加（注意，按照数据库基本思想——B+树，查询性能可能呈几何级的变化也可能差异不大）。这些值所代表的查询动作，在后文中会详细进行介绍；
• possible_keys：本次子查询可能使用的索引（前提是，您要建立了索引）。如果查询所使用的检索条件可能涉及到多个索引，这里将会列出这些所有的可能性；
• key: 本次子查询最终被选定的执行索引。有的时候possible_keys可能有值，但keys可能没有，这就代表InnoDB引擎最终并没有使用任何索引作为检所依据；
• key_len： 被选定的索引键的长度；
• ref：表示本次子查询参照的参照条件/参照数据表，参照条件/参照数据表，这个字段的值还可能是一个常量；
• rows： 执行根据目前数据表的实际情况预估的，完成这个子查询需要扫描的数据行数；
• Extra：包含不适合在其他列中显示但十分重要的额外信息。这个字段所呈现的信息在后文也会进行详细说明。

---

二、关键性能点

在我们根据SQL的执行计划进行查询语句和索引调整时，我们主要需要注意以下这些字段显示的值，以及它们背后所代表的性能表述。它们是：select_type列、type列、Extra列和key列。

1、select_type概要说明

一个复杂的SQL查询语句，在进行执行时会被拆分成若干个子查询。这些子查询根据存在的位置、执行先后顺序等要素被分解为不同的操作类型。当然还有的操作可能不涉及到任何实际数据表，例如两个子查询间的连接操作过程。在执行计划分析结果的select_type列，显示了拆分后这些子查询的类型，它们是：

• SIMPLE（常见）：简单的 SELECT查询。没有表UNION查询，没有子查询（嵌套查询）。我们在本节之前内容中给出的示例基本上属于这种查询类型，它基本上不需要也不能再进行子查询拆分；

• PRIMARY（常见）：由子查询（嵌套查询）的SQL语句下，最外层的Select 作为primary 查询；

• DERIVED（常见）：在from语句块中的子查询，属于衍生查询。例如以下的查询中接在“from”后面的子查询就属于这种类型的子查询：

EXPLAIN SELECT id FROM (SELECT * FROM myuser) temp;

• SUBQUERY 和 DEPENDENT SUBQUERY：这两种类型都表示第一个查询是子查询。区别是SUBQUERY表示的子查询不依赖于外部查询，而后者的子查询依赖于外部查询；

• UNCACHEABLE SUBQUERY：子查询结果不能被缓存， 而且必须重写（分析）外部查询的每一行；

• UNION：从第二个或者在union 之后的select 作为 union 查询。这种查询类型出现在结果集与结果集的UNION操作中；

• UNION RESULT：结果集是通过union 而来的。这种查询类型出现在结果集与结果集的UNION操作中；

• DEPENDENT UNION：从第二个或者在union 之后的select 作为 union 查询， 依赖于外部查询。这种查询类型出现在结果集与结果集的UNION操作中；

• UNCACHEABLE UNION：第二个 或者 在UNION 查询之后的select ,属于不可缓存的查询。这种查询类型出现在结果集与结果集的UNION操作中；

2、type概要说明

执行计划的type列中，主要说明了子查询的执行方式。它的值可能有如下的这些项目（根据MySQL数据库的执行引擎和版本还会有一些其它选项）：

• ALL：全表扫描，实际上是扫描数据表的聚簇索引，并在其上加锁还会视事务隔离情况加GAP间隙锁。在数据量非常少的情况下，做全表扫描和使用聚簇索引检索当然不会有太大的性能差异。但是数据量一旦增多情况就完全不一样了；

• index：进行索引的扫描，它和ALL一样都是扫描，不同点是index类型的扫描只扫描索引信息，并不会对聚簇索引上对应的数据值进行任何形式的读取。例如基于主键的函数统计：

# 以下语句还是要进行全表扫描，但是它并不需要读取任何数据信息。explain select count(*) from myuser

• range：在索引（聚簇索引和非聚簇索引都有可能）的基础上进行检索某一个范围内满足条件的范围，而并不是指定的某一个或者某几个值，例如：

# 以下查询语句在聚簇索引上检索一个范围explain select * from myuser where id >= 10

• ref：在非聚簇索引的基础上使用“非唯一键索引”的方式进行查找。例如：

# 在myuser中已基于user_name字段建立了非聚簇索引，且并非唯一键索引explain select count(*) from myuser where user_name = '用户1'

• const | system：const可以理解为“固定值”查询，常见于使用主键作为“简单查询”的条件时。system是比较特殊的const，当这个数据表只有一行的情况下，出现system类型。例如以下查询的操作类型就是const：

# 直接使用主键值就可以在索引中进行定位，无论数据量多大，这个定位的性能都不会改变explain select * from myuser where id = 1

3、Extra概要说明

执行计划分析结果中的Extra字段，包含了结果中其他字段中没有说明但是对性能分析有非常有帮助的信息。甚至有的时候可以但从这个字段分析出某个子查询是否需要调整、涉及到的索引是否需要调整或者MySQL服务的环境参数配置是否需要进行调整。Extra字段还可以看成是对特定子查询的总结。

• Using index：使用了索引（无论是聚簇索引还是非聚簇索引）并且整个子查询都只是访问了索引信息，而没有访问真实的数据信息，那么在Extra字段就会出现这个描述。请看如下示例：

explain select user_name from myuser where user_name = '用户1';+--------+-------------------------------------+| ...... |                Extra                |+--------+-------------------------------------+| ...... |     Using where; Using index        |+--------+-------------------------------------+# 使用user_name字段进行查询，原本需要再从聚簇索引中查找数据信息# 但是InnoDB引擎发现只需要输出一个字段，且这个字段就是user_name本身，甚至不需要去找全部数据了。

• Using where 和 Using index condition：此where关键字并不是SQL查询语句中的where关键字（此where非彼where），而是指该子查询是否需要依据一定的条件对满足条件的索引（全表扫描也是扫描的聚簇索引）进行过滤。示例如下：

# user_number 是一个非聚簇唯一键索引，所以where条件后的user_number只会定位到唯一一条记录# 不需要再根据这个条件查询是否还有其它满足条件的索引项了explain select * from myuser where user_number = 77777+--------+-------------+| ...... |    Extra    |+--------+-------------+| ...... |             |+--------+-------------+# user_name 是一个非聚簇非唯一键索引，索引where条件后的user_name可能定位到多条记录# 这时数据库引擎就会对这些索引进行检索，以便定位满足查询条件的若干索引项#（由于B+树的结构，所以这些索引项是连续的）explain select * from from myuser where user_name = '用户1'+--------+------------------------------+| ...... |              Extra           |+--------+------------------------------+| ...... |   Using index condition      |+--------+------------------------------+

为什么以上示例中显示的是“Using index condition”而不是“Using where”呢？

这是MySQL Version 5.6+ 的新功能特性，Index Condition Pushdown (ICP)。简单的说就是减少了查询执行时MySQL服务和下层数据引擎的交互次数，达到提高执行性能的目的。如果您关闭MySQL服务中的ICP功能（这个功能默认打开），以上示例的第二个执行语句就会显示“Using where”了。

• Using temporary：Mysql中的数据引擎需要建立临时表进行中间结果的记录，才能完成查询操作。
  这个常见于查询语句中存在 GROUP BY 或者 ORDER BY 操作的情况。但并不是说主要子查询中出现了GROUP BY 或者 ORDER BY就会建立临时表，而如果 Group By 或者 Order By 所依据的字段（或多个字段）没有建立索引，则一定会出现“Using temporary”这样的提示。另一种常见情况发生在子查询join连接时，连接所依据的一个字段（或多个字段）没有建立物理外键和索引。一旦在Extra字段中出现了“Using temporary”提示，一般来说这条子查询就需要重点优化；

• Using filesort：Mysql服务无法直接使用索引完成排序时，就需要动用一个内存空间甚至需要磁盘交换动作辅助才能完成排序操作。
  这句话有两层含义，如果排序所依据的字段（一个或者多个）并没有创建索引，那么肯定无法基于索引完成排序；即使排序过程能够依据正确的索引完成，但是由于涉及到的查询结果太多，导致用于排序的内存空间不足，所以MySQL服务在进行排序时还会有磁盘交换动作。负责配置某一个客户（session）可用的内存空间参数项名字为“sort_buffer_size”。默认的大小为256KB，如果读者对查询结果集有特别要求，可以将该值改为1MB。一旦在Extra字段中出现了“Using filesort”提示，那么说明这条子查询也需要进行优化；

explain select * from myuser order by usersex+--------+-----------------------+| ...... |          Extra        |+--------+-----------------------+| ...... |   Using filesort      |+--------+-----------------------+# 由于usersex并没有创建索引，所以使用filesort策略进行排序。

注意，在子查询中为Group By和Order by操作创建索引时，有时需要联合where关键字使用的查询字段一起创建复合索引才能起作用。这是因为子查询为了检索，所首先选择一个可用的索引项，随后进行排序时，却发现无法按照之前的索引进行排序，所以只有走filesort了。例如以下示例：

# user_name字段和user_number字段都独立创建了索引explain select * from myuser where user_name = '用户1' group by user_number+--------+------------+----------------------------------------------------------+| ...... |    key     |                             Extra                        |+--------+------------+----------------------------------------------------------+| ...... | name_index |  Using index condition; Using where; Using filesort      |+--------+------------+----------------------------------------------------------+# 为了首先完成条件检索，InnoDB引擎选择了user_name字段的索引# 但是排序时发现无法按照之前的索引字段完成，所以选择走filesort

• Using join buffer：使用InnoDB引擎预留的 join buffer 区域（一个专门用来做表连接的内存区域），这是一个正常现象主要涉及到两个子查询通过join关键字进行连接的操作。每一个客户端连接（session）独立使用的 join buffer 区域大小可以通过join_buffer_size参数进行设置。这个参数在 MySQL 5.6 Version 中的默认值为128KB。如果开发人员经常需要用到join操作，可以适当增加区域大小到1MB或者2MB；

# 以下语句是一个左外连接的操作# 并且t_interfacemethod.uid和t_interfacemethod_param.interfacemethod之间有外键和索引存在explain select * from  t_interfacemethod_param left join  t_interfacemethod on t_interfacemethod.uid = t_interfacemethod_param.interfacemethod+--------+----------------------------------------------------------+| ...... |                          Extra                           |+--------+----------------------------------------------------------+| ...... |                                                          |+--------+----------------------------------------------------------+| ...... |  Using where; Using join buffer (Block Nested Loop)      |+--------+----------------------------------------------------------+

---

三、执行计划的局限性

• 执行计划不考虑Query Cache：执行计划只考虑单次语句的执行效果，但实际上MySQL服务以及上层业务系统一般都会有一些缓存机制，例如MySQL服务中提供的Query Cache功能。所以实际上可能查询语句的重复执行速度会快一些；

• 执行计划不能分析insert语句：insert语句的执行效果实际上是和其他语句相互作用的，所以执行计划不能单独分析insert语句的执行效果。不过update和delete语句都是可以分析的（请使用MySQL Version 5.6+ 版本）；

• 执行计划不考虑可能涉及的存储过程、函数、触发器带来的额外性能消耗。

总的来说经过各个MySQL版本对执行计划功能的优化，现在这个功能得到的分析结果已经非常接近真实执行效果了。但是MySQL执行性能最关键的依据还是各位技术人员的数据库设计能力，起飞吧程序猿！