MySQL高级知识（四）——Explain

前言：explain（执行计划），使用explain关键字能够模拟优化器执行sql查询语句，从而知道MySQL是如何处理sql语句。explain主要用于分析查询语句或表结构的性能瓶颈。

注：本系列随笔如无特殊说明都MySQL版本都为5.7.22。

1.explain的做用

经过explain+sql语句能够知道以下内容：

①表的读取顺序。（对应id）

②数据读取操做的操做类型。（对应select_type）

③哪些索引可使用。（对应possible_keys）

④哪些索引被实际使用。（对应key）

⑤表直接的引用。（对应ref）

⑥每张表有多少行被优化器查询。（对应rows）

2.explain包含的信息

explain使用：explain+sql语句，经过执行explain能够得到sql语句执行的相关信息。

下面对explain的表头字段含义进行解释。

注：下图中有些explain表头不包含partitions和filtered字段，是由于有些截图是直接从视频资料中截取的，当并不影响咱们的分析。

①id

select查询的序列号，包含一组数字，表示查询中执行select子句或操做表的顺序，该字段一般与table字段搭配来分析。

#1.id相同，执行顺序从上到下。

id相同，执行顺序从上到下，搭配table列进行观察可知，执行顺序为t1->t3->t2。

#2.id不一样，若是是子查询，id的序号会递增，id值越大执行优先级越高。

若是是子查询id的序号会递增，id值越大执行优先级越高，搭配table列可知，执行顺序为t3->t1->t2。

#3.id相同不一样，同时存在。

id若是相同，可认为是同一组，执行顺序从上到下。在全部组中，id值越大执行优先级越高。因此执行顺序为t3->derived2(衍生表，也能够说临时表)->t2。

总结：id的值表示select子句或表的执行顺序，id相同，执行顺序从上到下，id不一样，值越大的执行优先级越高。

②select_type

查询的类型，主要用于区别普通查询、联合查询、子查询等复杂的查询。其值主要有六个：

#1.SIMPLE

简单的select查询，查询中不包含子查询或union查询。

#2.PRIMARY

查询中若包含任何复杂的子部分，最外层查询为PRIMARY，也就是最后加载的就是PRIMARY。

#3.SUBQUERY

在select或where列表中包含了子查询，就为被标记为SUBQUERY。

#4.DERIVED

在from列表中包含的子查询会被标记为DERIVED(衍生)，MySQL会递归执行这些子查询，将结果放在临时表中。

#5.UNION

若第二个select出如今union后，则被标记为UNION，若union包含在from子句的子查询中，外层select将被标记为DERIVED。

#6.UNION RESULT

从union表获取结果的select。

③table

显示sql操做属于哪张表的。

④partitions

官方定义为The matching partitions（匹配的分区），该字段应该是看table所在的分区吧（不晓得理解错误没）。值为NULL表示表未被分区。

⑤type

表示查询所使用的访问类型，type的值主要有八种，该值表示查询的sql语句好坏，从最好到最差依次为：system>const>eq_ref>ref>range>index>ALL。

要详细了解type取值的做用，须要用数听说话。建立tb_emp（员工表）和tb_dept（部门表）。

a）tb_emp表。

DROP TABLE IF EXISTS `tb_emp`;
CREATE TABLE `tb_emp` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(20) NOT NULL,
  `deptid` int(11) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_tb_emp_name` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

INSERT INTO `tb_emp`(name,deptid) VALUES ('jack', '1');
INSERT INTO `tb_emp`(name,deptid) VALUES ('tom', '1');
INSERT INTO `tb_emp`(name,deptid) VALUES ('tonny', '1');
INSERT INTO `tb_emp`(name,deptid) VALUES ('mary', '2');
INSERT INTO `tb_emp`(name,deptid) VALUES ('rose', '2');
INSERT INTO `tb_emp`(name,deptid) VALUES ('luffy', '3');
INSERT INTO `tb_emp`(name,deptid) VALUES ('outman', '4');

b）tb_dept表。

DROP TABLE IF EXISTS `tb_dept`;
CREATE TABLE `tb_dept` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `deptname` varchar(20) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

INSERT INTO `tb_dept`(deptname) VALUES ('研发');
INSERT INTO `tb_dept`(deptname) VALUES ('测试');
INSERT INTO `tb_dept`(deptname) VALUES ('运维');
INSERT INTO `tb_dept`(deptname) VALUES ('经理');

#1.system

表只有一行记录（等于系统表），是const的特例类型，平时不会出现，能够忽略不计。

可是笔者发如今MySQL5.7.22时，不会出现该字段值，只能出现const，可是在MySQL5.7版本如下能够出现该状况。猜想MySQL5.7版本是否是进行了优化，由于system官网的解释：

5.5.48：

5.7.22：

注：两个引擎的执行信息不同，5.5.48执行过程当中产生了临时表（DERIVED），5.7.22为简单查询。

#2.const

表示经过一次索引就找到告终果，常出现于primary key或unique索引。由于只匹配一行数据，因此查询很是快。如将主键置于where条件中，MySQL就能将查询转换为一个常量。

注：对于system和const可能实际意义并非很大，由于单表单行查询原本就快，意义不大。

#3.eq_ref

惟一索引扫描，对于每一个索引键，表中只有一条记录与之匹配。常见主键或惟一索引扫描。

注：经理只有一人，进行了tb_dept的主键扫描。

#4.ref

非惟一性索引扫描，返回匹配某个单独值的全部行。本质上也是一种索引访问，返回匹配某值（某条件）的多行值，属于查找和扫描的混合体。

因为是非惟一性索引扫描，因此对tb_emp表的deptid字段建立索引：

create index idx_tb_emp_deptid on tb_emp(deptid);

#5.range

只检索给定范围的行，使用一个索引来检索行，能够在key列中查看使用的索引，通常出如今where语句的条件中，如使用between、>、<、in等查询。

这种索引的范围扫描比全索引扫描要好，由于索引的开始点和结束点都固定，范围相对较小。

虽然咱们为deptid字段建立了索引并在where中使用了between等，但在以下状况type仍为ALL。

对比两图，能够看到使用deptid和id进行操做，其type的值一个是ALL也就是进行了全表扫描，一个是range进行了指定索引范围值检索。可能缘由deptid并非惟一索引。

对于以上问题，须要具体问题具体分析，并不能一律而论。

#6.index

全索引扫描，index和ALL的区别：index只遍历索引树，一般比ALL快，由于索引文件一般比数据文件小。虽然说index和ALL都是全表扫描，可是index是从索引中读取，ALL是从磁盘中读取。

#7.ALL

全表扫描。

注：通常来讲，需保证查询至少达到range级别，最好能达到ref。

⑥possible_keys和key、key_len

possible_keys：显示可能应用在表中的索引，可能一个或多个。查询涉及到的字段若存在索引，则该索引将被列出，但不必定被查询实际使用。

key：实际中使用的索引，如为NULL，则表示未使用索引。若查询中使用了覆盖索引，则该索引和查询的select字段重叠。

key_len：表示索引中所使用的字节数，可经过该列计算查询中使用的索引长度。在不损失精确性的状况下，长度越短越好。key_len显示的值为索引字段的最大可能长度，并不是实际使用长度，即key_len是根据表定义计算而得，并非经过表内检索出的。

简单理解：possible_keys表示理论上可能用到的索引，key表示实际中使用的索引。

possible_keys为NULL表示可能未用到索引，但key=idx_deptid表示在实际查询的过程当中进行了索引的全扫描。

经过下面的例子来理解key_len，首先为name字段建立索引：

create index idx_name on tb_emp(name);

注：在使用索引查询时，当条件越精确，key_len的长度可能会越长，因此在不影响结果的状况下，key_len的值越短越好。

⑦ref

显示关联的字段。若是使用常数等值查询，则显示const，若是是链接查询，则会显示关联的字段。

注：因为id相同，所以从上到下执行：

#1.tb_emp表为非惟一性索引扫描，实际使用的索引列为idx_name，因为tb_emp.name='rose'为一个常量，因此ref=const。

#2.tb_dept为惟一索引扫描，从sql语句能够看出，实际使用了PRIMARY主键索引，ref=db01.tb_emp.deptid表示关联了db01数据库中tb_emp表的deptid字段。

⑧rows

根据表统计信息及索引选用状况大体估算出找到所需记录所要读取的行数。固然该值越小越好。

⑨filtered

百分比值，表示存储引擎返回的数据通过滤后，剩下多少知足查询条件记录数量的比例。

⑩Extra

显示十分重要的额外信息。其取值有如下几个：

#1.Using filesort

Using filesort代表mysql会对数据使用一个外部的索引排序，而不是按照表内的索引顺序进行读取。

mysql中没法利用索引完成的排序操做称为“文件排序”。

出现Using filesort就很是危险了，在数据量很是大的时候几乎“九死一辈子”。出现Using filesort尽快优化sql语句。

deptname字段未建索引的状况。

为deptname字段建立索引后。

#2.Using temporary

使用了临时表保存中间结果，常见于排序order by和分组查询group by。很是危险，“十死无生”，急需优化。

将tb_emp中name的索引先删除，出现以下图结果，很是烂，Using filesort和Using temporary，“十死无生”。

为name字段建立索引后。

#3.Using index

代表相应的select操做中使用了覆盖索引，避免访问表的额外数据行，效率不错。

若是同时出现了Using where，代表索引被用来执行索引键值的查找。（where deptid=1）

若是没有同时出现Using where，代表索引用来读取数据而非执行查找动做。

删除tb_emp表中name和deptid字段的单独索引，建立复合索引。

从这里给出覆盖索引的定义：select的数据列只从索引中就能取得数据，没必要读取数据行。经过上面的例子理解：建立了（name，deptid）的复合索引，查询的时候也使用复合索引或部分，这就造成了覆盖索引。简记：查询使用复合索引，而且查询的列就是索引列，不能多，个数需对应。

使用优先级Using index>Using filesort（九死一辈子）>Using temporary（十死无生）。也就说出现后面两项代表sql语句是很是烂的，急需优化！！！

总结

explain（执行计划）包含的信息十分的丰富，着重关注如下几个字段信息。

①id，select子句或表执行顺序，id相同，从上到下执行，id不一样，id值越大，执行优先级越高。

②type，type主要取值及其表示sql的好坏程度（由好到差排序）：system>const>eq_ref>ref>range>index>ALL。保证range，最好到ref。

③key，实际被使用的索引列。

④ref，关联的字段，常量等值查询，显示为const，若是为链接查询，显示关联的字段。

⑤Extra，额外信息，使用优先级Using index>Using filesort（九死一辈子）>Using temporary（十死无生）。

着重关注上述五个字段信息，对平常生产过程当中调优十分有用。

---

by Shawn Chen，2018.6.22日，下午。

---

相关内容

MySQL高级知识系列目录