Mysql深入探索之Explain执行计划详析
前言
如何写出效率高的SQL语句，提到这必然离不开Explain执行计划的分析，至于什么是执行计划，如何写出高效率的SQL，本篇文章将会一一介绍。
执行计划
执行计划是数据库根据SQL语句和相关表的统计信息作出的一个查询方案，这个方案是由查询优化器自动分析产生的。
使用explain关键字可以模拟优化器执行SQL查询语句，从而知道MySQL是如何处理你的SQL语句的，分析你的select语句或是表结构的性能瓶颈，让我们知道select效率低下的原因，从而改进我们的查询。
explain的结果如下：
下面是有关各列的详细介绍，重要的有id、type、key、rows、extra。
id
- id列的编号就是select的序列号，也可以理解为SQL执行顺序的标识，有几个select就有几个id。
- id值不同：如果是只查询，id的序号会递增，id值越大优先级越高，越先被执行；
- id值相同：从上往下依次执行；
- id列为null：表示这是一个结果集，不需要使用它来进行查询。
select_type
查询的类型，主要用于区分普通查询、联合查询、子查询等复杂的查询；
simple：表示查询中不包括union操作或者子查询，位于最外层的查询的select_type即为simple，且只有一个；
explainselect*fromt3whereid=3952602;
primary：需要union操作或者含有子查询的select，位于最外层的查询的select_type即为primary，且只有一个；
explainselect*from(select*fromt3whereid=3952602)a;
derived：from列表中出现的子查询，也叫做衍生表；mysql或者递归执行这些子查询，把结果放在临时表里。
explainselect*from(select*fromt3whereid=3952602)a;
subquery：除了from子句中包含的子查询外，其他地方出现的子查询都可能是subquery。
explainselect*fromt3whereid=(selectidfromt3whereid=3952602);
union：若第二个select出现在union之后，则被标记为union；若union包含在from子句的子查询中，外层select将被标记为derived。
explainselect*fromt3whereid=3952602unionallselect*fromt3;
unionresult：从union表获取结果的select，因为它不需要参与查询，所以id字段为null。
explainselect*fromt3whereid=3952602unionallselect*fromt3;
dependentunion：与union一样，出现在union或unionall语句中，但是这个查询要受到外部查询的影响；
dependentsubquery：与dependentunion类似，子查询中的第一个SELECT，这个subquery的查询要受到外部表查询的影响。
table
表示explain的一行正在访问哪个表。
- 如果查询使用了别名，那么这里显示的是别名;
- 如果不涉及对数据表的操作，那么这显示为null;
- 如果显示为尖括号括起来的就表示这个是临时表，后边的N就是执行计划中的id，表示结果来自于这个查询产生;
- 如果是尖括号括起来的
type
访问类型，即MySQL决定如何查找表中的行。
依次从好到差：system>const>eq_ref>ref>fulltext>ref_or_null>index_merge>unique_subquery>index_subquery>range>index>ALL，除了all之外，其他的type都可以使用到索引，除了index_merge之外，其他的type只可以用到一个索引。一般来说，得保证查询至少达到range级别，最好能达到ref。
- system：表中只有一行数据（等于系统表），这是const类型的特例，平时不会出现，可以忽略不计。
- const：使用唯一索引或者主键，表示通过索引一次就找到了，const用于比较primarykey或者unique索引。因为只需匹配一行数据，所有很快。如果将主键置于where列表中，mysql就能将该查询转换为一个const。
- eq_ref：唯一性索引扫描，对于每个索引键，表中只有一行数据与之匹配。常见于主键或唯一索引扫描。
- ref：非唯一性索引扫描，返回匹配某个单独值的所有行。本质也是一种索引。
- fulltext：全文索引检索，全文索引的优先级很高，若全文索引和普通索引同时存在时，mysql不管代价，优先选择使用全文索引。
- ref_or_null：与ref方法类似，只是增加了null值的比较。
- index_merge：表示查询使用了两个以上的索引，索引合并的优化方法，最后取交集或者并集，常见and，or的条件使用了不同的索引。
- unique_subquery：用于where中的in形式子查询，子查询返回不重复值唯一值；
- index_subquery：用于in形式子查询使用到了辅助索引或者in常数列表，子查询可能返回重复值，可以使用索引将子查询去重。
- range：索引范围扫描，常见于使用>,<,between,in,like等运算符的查询中。
- index：索引全表扫描，把索引树从头到尾扫一遍；
- all：遍历全表以找到匹配的行（Index与ALL虽然都是读全表，但index是从索引中读取，而ALL是从硬盘读取）
- NULL:MySQL在优化过程中分解语句，执行时甚至不用访问表或索引。
possible_keys
显示查询可能使用到的索引。
key
显示查询实际使用哪个索引来优化对该表的访问；
select_type为index_merge时，这里可能出现两个以上的索引，其他的select_type这里只会出现一个。
key_len
- 用于处理查询的索引长度，表示索引中使用的字节数。通过这个值，可以得出一个多列索引里实际使用了哪一部分。
- 注：key_len显示的值为索引字段的最大可能长度，并非实际使用长度，即key_len是根据表定义计算而得，不是通过表内检索出的。另外，key_len只计算where条件用到的索引长度，而排序和分组就算用到了索引，也不会计算到key_len中。
ref
显示哪个字段或者常数与key一起被使用。
- 如果是使用的常数等值查询，这里会显示const。
- 如果是连接查询，被驱动表的执行计划这里会显示驱动表的关联字段。
- 如果是条件使用了表达式或者函数，或者条件列发生了内部隐式转换，这里可能显示为func。
rows
表示MySQL根据表统计信息及索引选用情况，大致估算的找到所需的目标记录所需要读取的行数，不是精确值。
extra
不适合在其他列中显示但十分重要的额外信息。
这个列可以显示的信息非常多，有几十种，常用的有：
| 类型 | 说明 |
|---|---|
| Usingfilesort | MySQL有两种方式可以生成有序的结果，通过排序操作或者使用索引，当Extra中出现了Usingfilesort说明MySQL使用了后者，但注意虽然叫filesort但并不是说明就是用了文件来进行排序，只要可能排序都是在内存里完成的。大部分情况下利用索引排序更快，所以一般这时也要考虑优化查询了。使用文件完成排序操作，这是可能是orderyby，groupby语句的结果，这可能是一个CPU密集型的过程，可以通过选择合适的索引来改进性能，用索引来为查询结果排序。 |
| Usingtemporary | 用临时表保存中间结果，常用于GROUPBY和ORDERBY操作中，一般看到它说明查询需要优化了，就算避免不了临时表的使用也要尽量避免硬盘临时表的使用。 |
| Notexists | MYSQL优化了LEFTJOIN，一旦它找到了匹配LEFTJOIN标准的行，就不再搜索了。 |
| Usingindex | 说明查询是覆盖了索引的，不需要读取数据文件，从索引树（索引文件）中即可获得信息。如果同时出现usingwhere，表明索引被用来执行索引键值的查找，没有usingwhere，表明索引用来读取数据而非执行查找动作。这是MySQL服务层完成的，但无需再回表查询记录。 |
| Usingindexcondition | 这是MySQL5.6出来的新特性，叫做“索引条件推送”。简单说一点就是MySQL原来在索引上是不能执行如like这样的操作的，但是现在可以了，这样减少了不必要的IO操作，但是只能用在二级索引上。 |
| Usingwhere | 使用了WHERE从句来限制哪些行将与下一张表匹配或者是返回给用户。注意：Extra列出现Usingwhere表示MySQL服务器将存储引擎返回服务层以后再应用WHERE条件过滤。 |
| Usingjoinbuffer | 使用了连接缓存：BlockNestedLoop，连接算法是块嵌套循环连接;BatchedKeyAccess，连接算法是批量索引连接 |
| impossiblewhere | where子句的值总是false，不能用来获取任何元组 |
| selecttablesoptimizedaway | 在没有GROUPBY子句的情况下，基于索引优化MIN/MAX操作，或者对于MyISAM存储引擎优化COUNT(*)操作，不必等到执行阶段再进行计算，查询执行计划生成的阶段即完成优化。 |
| distinct | 优化distinct操作，在找到第一匹配的元组后即停止找同样值的动作 |
filtered
- 使用explainextended时会出现这个列，5.7之后的版本默认就有这个字段，不需要使用explainextended了。
- 这个字段表示存储引擎返回的数据在server层过滤后，剩下多少满足查询的记录数量的比例，注意是百分比，不是具体记录数。
关于MySQL执行计划的局限性
- EXPLAIN不会告诉你关于触发器、存储过程的信息或用户自定义函数对查询的影响情况；
- EXPLAIN不考虑各种Cache；
- EXPLAIN不能显示MySQL在执行查询时所作的优化工作；
- 部分统计信息是估算的，并非精确值；
- EXPALIN只能解释SELECT操作，其他操作要重写为SELECT后查看。
查询计划案例分析
执行顺序
- （id=4）：【selectid,namefromt2】：select_type为union，说明id=4的select是union里面的第二个select。
- （id=3）：【selectid,namefromt1whereaddress=‘11'】：因为是在from语句中包含的子查询所以被标记为DERIVED（衍生），whereaddress=‘11'通过复合索引idx_name_email_address就能检索到，所以type为index。
- （id=2）：【selectidfromt3】：因为是在select中包含的子查询所以被标记为SUBQUERY。
- （id=1）：【selectd1.name,…d2from…d1】：select_type为PRIMARY表示该查询为最外层查询，table列被标记为“derived3”表示查询结果来自于一个衍生表（id=3的select结果）。
- （id=NULL）：【…union…】：代表从union的临时表中读取行的阶段，table列的“union1,4”表示用id=1和id=4的select结果进行union操作。
总结
到此这篇关于Mysql深入探索之Explain执行计划的文章就介绍到这了,更多相关MysqlExplain执行计划内容请搜索毛票票以前的文章或继续浏览下面的相关文章希望大家以后多多支持毛票票！
声明：本文内容来源于网络，版权归原作者所有，内容由互联网用户自发贡献自行上传，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任。如果您发现有涉嫌版权的内容，欢迎发送邮件至：czq8825#qq.com（发邮件时，请将#更换为@）进行举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。