MySQL高级知识（五）——Explain

此博客的内容主要来源于尚硅谷的视频中，在此记录，以备以后自己查看。

使用Explain关键字可以模拟优化器执行SQL查询语句，从而知道MySQL是如何处理你的SQL语句的。分析你的查询语句或是表结构的性能瓶颈。

1. Explain作用

通过explain+sql语句可以知道下面内容：
1. 表的读取顺序（对应id）
2. 数据读取操作的操作类型（对应select_type）
3. 哪些索引可以使用（对应possible_keys）
4. 哪些索引被实际使用（对应key）
5. 表直接的引用（对应ref）
6. 每张表有多少行被优化器查询（对应rows）

2. Explain包含的信息

explain使用：explain+sql语句，通过执行explain可以获取sql语句执行的相关信息。

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

2.1. id

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

1. id相同，执行顺序从上至下。
   
   此例中先执行where后的第一条语句t1.id=t2.id通过t1.id关联t2.id.而t2.i 的结果建立在 t2.id=t3.id的基础之上。
   id相同，执行顺序从上到下，搭配table列进行观察可知，执行顺序为t1->t3->t2。

2. id不同，如果是子查询，id的序号会递增，id值越大执行优先级越高。
   
   如果是子查询，id的序号会递增，id越大则执行优先级就越高，因此搭配table列可知，执行顺序为t3->t2->t1。

3. id相同不同，同时存在。
   
   id如果相同，可以认为是一组，从上往下顺序执行；在所有组中，id值越大，优先级越高，越先执行。
   所以执行顺序为t3->derived2->t2.

衍生表 = derived2 --> derived + 2 （2 表示由 id =2 的查询衍生出来的表。type 肯定是 all ，因为衍生的表没有建立索引）

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

2.2. 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。

2.3. table

显示sql操作执行的属于哪张表的。

2.4. partitions

官方定义为The matching partitions（匹配的分区），值为NULL表示表未被分区。

2.5. type

type显示的是访问类型，是较为重要的一个指标，结果值从最好到最坏依次是：
system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range(尽量保证) > index > ALL
一般来说，得保证查询至少达到range级别，最好能达到ref。

例如：
创建emp表：

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

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

创建dept表：

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

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

1. system
   表只有一行记录（等于系统表），是const的特殊类型，平时不会出现，可以忽略（5.7版本以后不出现）
2. const
   表示通过一次索引就找到了结果，常出现primary key或者unique索引。因为只匹配一行数据，所以查询非常快。如将主键置于where条件中，MySQL就能将查询转换为一个常量。
   
3. eq_ref
   唯一性索引扫描，对于每个索引键，表中只有一条记录与之匹配。常见主键或唯一索引扫描。
   
   注意：经理只有一个人，进行了dept的主键扫描。
4. ref
   非唯一性索引扫描，返回匹配某个单独值得所在行。本质上也是一种索引访问，他返回所有匹配某个单独值的行，然后他可能找到多个符合条件的行，所以他应该属于查找和扫描的混合体。

例如：

• 由于是非唯一性索引扫描，所以对emp表的deptid字段创建索引：
  create index idx_emp_deptid on emp(deptid);
  
• 执行sql语句：
  

5. range
   只检索给定范围的行，使用一个索引来检索行，可以在key列中查看使用的索引，一般出现在where语句的条件中，如使用between、>、<、in等查询。
   这种索引的范围扫描比全表扫描要好，因为索引的开始点和结束点都固定，不用扫描全索引。

例如：

• 索引deptid
  
  上图是根据我们创建的deptid字段的索引查询范围>的结果；
  
  上图是根据我们创建的deptid字段的索引查询范围between的结果，尽管创建了索引，但是type仍然为all。
  
  上图是根据我们创建的deptid字段的索引查询范围in的结果，尽管创建了索引，但是type仍然为all。

• 主键id
  
  上图是根据主键id字段的索引查询范围>的结果；
  
  上图是根据主键id字段的索引查询范围between的结果，与deptid索引的此结果对比，发现主键id的between查询结果为range，而deptid的结果是all全表扫描。
  
  上图是根据主键id字段的索引查询范围in的结果，与deptid索引的此结果对比，发现主键id的in查询结果为range，而deptid的查询结果是all全表扫描。

出现此处的原因可能是deptid不是唯一索引

6. index
   全索引扫描。index与all的区别：index只遍历索引树，通常比ALL快，因为索引文件通常比数据文件小。(也就是说，虽然index和ALL都是读取全表，但是index是从索引中读取，而ALL是从硬盘中读取的)

7. ALL
全表扫描。将遍历全表以找到匹配的行。

2.6. possible_keys和key、key_len

• possible_keys：显示可能应用在这张表中的索引，一个或者多个。查询设计的字段若存在索引，则该索引将被列出，但是不一定被查询实际使用。
• key：实际中使用的索引，如果未NULL，则表示没有使用索引。查询中若使用了覆盖索引，则该索引和查询的select字段重叠。

事例：


对比上面两个sql语句，我们发现：当查询具体的某一个字段时候，且那个字段有索引的时候，key的值会显示未索引

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

计算：

char(30) utf8 --> key_len = 30*3 +1 表示 utf8 格式需要 *3 (跟数据类型有关)
允许为 NULL +1 ，不允许 +0
动态类型 +2 (动态类型包括 : varchar , detail text() 截取字符窜)

第一组：key_len=deptno(int)+null + ename(varchar(20)3+动态 =4+1+203+2= 67
第二组：key_len=deptno(int)+null=4+1=5

• 简单的理解：possible_keys表示理论上可能用到的索引，key表示实际中使用的索引。
  
  possible_keys为NULL表示可能未用到索引，但key=idx_deptid表示在实际查询的过程中进行了索引的全扫描。

2.7. ref

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

注意：因为id相同，因此从上到下执行；

1. emp表为非唯一性索引扫描，实际使用的索引列未idx_emp_name，由于emp.name='rose'为一个常量，所以ref=const.
2. dept表为唯一索引扫描，从sql与剧中可以看出，实际上使用的是primary主键索引，red=company.emp.deptid表示关联的company数据库中的emp表的deptid字段。

2.8. rows

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

2.9. filtered

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

2.10. extra

显示十分重要的额外信息。其取值包括以下几个：

1. Using filesort：
   • Using filesort表明mysql会对数据使用一个外部的索引排序，而不是按照表内的索引顺序进行读取。
   • mysql中无法利用索引完成的排序操作称为”文件排序“。
   • 出现Using filesort就非常危险了，在数据量非常大的时候几乎”九死一生“。出现Using filesort尽快优化sql语句。

如图，dept表的索引只有主键所对应的索引，所以做deptname排序之后出现Using filesort现象。

如图，先添加deptname字段的索引，之后执行sql后做的排序是通过索引做的排序。

查询中如果需要排序，如果排序字段通过索引去访问将大大地提高排序速度。

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

3. Using index

   • 表明相应的select操作中使用了覆盖索引，避免访问表的额外数据行，效率不错。
   • 如果同时出现了Using where，表明了索引被用来执行索引键值的查找。（where deptid=1）
   • 如果没有同时出现Using where，表明索引用来读取数据而非执行查找动作。

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

从这里给出覆盖索引的定义：select的数据列只从索引中就能取得数据，不必读取数据行。通过上面的例子理解：创建了（name，deptid）的复合索引，查询的时候也使用复合索引或部分，这就形成了覆盖索引。简记：查询使用复合索引，并且查询的列就是索引列，不能多，个数需对应。
覆盖索引包含了（覆盖了）select子句与查询条件where子句中的所需要的字段。

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

4. Using where
   表明使用了where过滤
5. using join buffer
   使用了连接缓存
6. impossible where
   where子句的值总是false，不能用来获取任何元组。
7. select tables optimized away
   在没有group by子句的i情况下，基于索引优化MIN/MAX操作或者对于MyISAM存储引擎优化COUNT(*)操作，不必等到执行阶段再进行计算，查询执行计划生成的阶段即完成优化。

3. 总结

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（十死无生）。

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