你会看MySQL的执行计划（EXPLAIN）吗？

　　SQL执行太慢怎么办？我们通常会使用EXPLAIN命令来查看SQL的执行计划，然后根据执行计划找出问题所在并进行优化。用法简介
　　EXPLAIN的用法很简单，只需要在你的SQL前面加上EXPLAIN即可。例如：explainselectfromt；
　　PS：insert、update、delete同样可以通过explain查看执行计划，不过通常我们更关心select的执行情况
　　你会看到如下输出：idselecttypetablepartitionstypepossiblekeyskeykeylenrefrowsfilteredExtra1SIMPLEt1NULLALLNULLNULLNULLNULL1100。00NULL1rowinset，1warning（0。00sec）
　　执行计划结果字段说明如下表：
　　字段
　　JSONName
　　说明
　　id
　　selectid
　　查询标识符
　　selecttype
　　查询类型
　　table
　　tablename
　　查询记录所在表
　　partitions
　　partitions
　　查询匹配的分区（没有进行表分区，则为NULL）
　　type
　　accesstype
　　连接类型
　　possiblekeys
　　possiblekeys
　　可以选择的索引
　　key
　　key
　　实际上用到的索引
　　keylen
　　keylength
　　被用到索引的长度，比如联合索引中有几个被用到
　　ref
　　ref
　　与索引相比较的列
　　rows
　　rows
　　要扫描的行数（估算值）
　　filtered
　　filtered
　　按表条件过滤的行百分比
　　Extra
　　附加信息
　　EXPLAIN的用法非常简单，看一眼就会。但是要根据输出结果找到问题并解决，就没那么容易了。就好比操作拍CT的机器可能相对简单，但要从CT成像中看出问题并给出治疗方案就需要丰富的知识和大量的临床经验了。
　　因此，我们需要知道每个字段代表什么指标；什么样的取值是我们想要的，什么样是需要优化的；最后还要知道如何优化成我们想要的值。字段详解id
　　标识符。查询操作的序列号。通常都是正整数，但当有UNION操作时，该值可以为NULL。
　　id相同explainselectfromt1wheret1。idin（selectt2。idfromt2）；idselecttypetablepartitionstypepossiblekeys。。。1SIMPLEt1NULLALLPRIMARY。。。。1SIMPLEt2NULLeqrefPRIMARY。。。。2rowsinset，1warning（0。00sec）
　　id不同explainselectfromt1wheret1。id（selectt2。idfromt2）；idselecttypetablepartitionstypepossiblekeys。。。1PRIMARYNULLNULLNULLNULL。。。。2SUBQUERYt2NULLindexNULL。。。。2rowsinset，1warning（0。00sec）
　　id包含NULLexplainselectidfromt1union（selectidfromt2）；idselecttypetablepartitionstypepossiblekeys。。。1PRIMARYt1NULLindexNULL。。。2UNIONt2NULLindexNULL。。。NULLUNIONRESULTunion1，2NULLALLNULL。。。3rowsinset，1warning（0。00sec）
　　id为NULL时，table列值为unionM，n格式，表示该行为id为m和n联合的结果
　　id顺序的规则：如果id相同，执行顺序由上到下；如果不同，执行顺序由大到小。selecttype
　　SELECT类型，常见的取值如下表：
　　查询类型
　　JSONName
　　说明
　　SIMPLE
　　简单SELECT（没有UNION或子查询）
　　PRIMARY
　　查询包含UNION或子查询，则最外层的查询被标识为PRIMARY
　　UNION
　　UNION中的第二个或更后面的SELECT语句
　　DEPENDENTUNION
　　dependent（true）
　　UNION中的第二个或更后面的SELECT语句，依赖于外部查询
　　UNIONRESULT
　　unionresult
　　UNION的结果
　　SUBQUERY
　　子查询中的第一个SELECT语句
　　DEPENDENTSUBQUERY
　　dependent（true）
　　子查询中的第一个SELECT语句，依赖于外部查询
　　DERIVED
　　派生表SELECT
　　DEPENDENTDERIVED
　　dependent（true）
　　派生表依赖于另一个表
　　MATERIALIZED
　　materializedfromsubquery
　　将子查询的结果物化（生成临时表）
　　UNCACHEABLESUBQUERY
　　cacheable（false）
　　结果无法缓存且必须为外部查询的每一行重新计算的子查询
　　UNCACHEABLEUNION
　　cacheable（false）
　　UNION中的第二个或更后面的SELECT语句，属于不可缓存子查询（参考UNCACHEABLESUBQUERY）UNION或者子查询MySQL会自动产生临时表。派生表可以简单理解为具有别名的临时表。生成临时表的这个动作称为物化（水变成蒸汽叫汽化）
　　临时表通常在内存里，当其size超过一定范围会被存入磁盘临时表selectfromt1joint2ont1。idt2。idwheret1。id1；派生表，临时表取个别名selectfrom（selectfromt1）t；type
　　连接字段为主键或者唯一索引，此类型通常出现于多表的join查询，表示对于前表的每一个结果，都对应后表的唯一一条结果。并且查询的比较是操作，查询效率比较高。
　　取值
　　说明
　　system
　　表中只有一条记录，const类型的特例
　　const
　　表中最多有一条匹配数据，用于主键或唯一索引的等值匹配
　　eqref
　　出现在多表查询中，前表结果中的每一条记录，在后表中有唯一的对应。同样是主键或唯一索引等值匹配
　　ref
　　普通索引的等值匹配（或）
　　fulltext
　　全文索引
　　refornull
　　跟ref类似，增加了对NULL的判断
　　indexmerge
　　合并索引（用到了两个及以上的索引）
　　uniquesubquery
　　子查询用到主键或唯一索引
　　indexsubquery
　　子查询用到普通索引
　　range
　　范围匹配（、、、、、、ISNULL、、BETWEEN、LIKE或IN）
　　index
　　扫描索引树（在覆盖索引的情况下优于ALL）
　　ALL
　　全表扫描
　　还有一种NULL的情况，比如selectmin（id）fromt1，但MySQL官方没有提及这种情况，所以我们不在此讨论
　　性能从优到劣依次为：
　　systemconsteqrefreffulltextrefornullindexmergeuniquesubqueryindexsubqueryrangeindexALL
　　优化原则：最好做到const，至少做到ref，避免ALLref
　　查询中用来和索引比较的类型，如：id1，值为const；如果是联合查询或者子查询则为关联的字段；如果使用了函数，则为func。Extra
　　Extra用来存放一些附加信息，通常用来配合type的输出来做SQL优化。扩展desc
　　desc与explain作用相同，可以互相代替，后面的例子中均使用desc来查看执行计划。format
　　explaindesc还支持一些参数，format顾名思义，是用来格式化输出结果的。它包括两种格式化方式：tree和json。
　　比如：descformattreeselectfromt1wheret1。idin（selectt2。idfromt2wheret2。id1）；
　　输出格式如下：EXPLAINNestedloopinnerjoin（cost0。70rows1）Filter：（t2。id1）（cost0。35rows1）Indexscanont2usinga2uidx（cost0。35rows1）Singlerowindexlookupont1usingPRIMARY（idt2。id）（cost0。35rows1）1rowinset（0。00sec）
　　执行计划结果以树形结构展示，可以清晰的看出语句之间的嵌套关系，还有基本的执行成本（cost）。
　　使用json方式：descformatjsonselectfromt1；
　　输出结构为一个JSON结构：EXPLAIN｛queryblock：｛selectid：1，costinfo：｛querycost：0。35｝，table：｛tablename：t1，accesstype：ALL，rowsexaminedperscan：1，rowsproducedperjoin：1，filtered：100。00，costinfo：｛readcost：0。25，evalcost：0。10，prefixcost：0。35，datareadperjoin：56｝，usedcolumns：〔id，a1，b1〕｝｝｝1rowinset，1warning（0。00sec）
　　简介表中的JSONName指的就是这里JSON结果的key
　　json格式会展示出更加详细的信息，可以看到执行成本划分的更加细致了，方便定位到慢SQL的问题具体出现在哪个环节。analyze
　　除了format以外，explaindesc还可以使用analyze参数：descanalyzeselectfromt1wheret1。idin（selectt2。idfromt2wheret2。id1）；
　　输出结果：EXPLAINNestedloopinnerjoin（cost0。70rows1）（actualtime0。018。。0。018rows0loops1）Filter：（t2。id1）（cost0。35rows1）（actualtime0。016。。0。016rows0loops1）Indexscanont2usinga2uidx（cost0。35rows1）（actualtime0。015。。0。015rows0loops1）Singlerowindexlookupont1usingPRIMARY（idt2。id）（cost0。35rows1）（neverexecuted）1rowinset（0。00sec）
　　可以看出，analyze的输出结果是基于formattree的
　　上面执行计划中（formatjsontree）的执行成本（cost）都是估值，而analyze中的执行成本是真实值。actualtime代表对应SQL执行的真实时间，单位为毫秒。最后
　　执行计划的结果中，我们最关心的是type，它能够最直接的反映出SQL执行效率处在什么级别。然后再结合其他字段（例如Extra）来做更细致的分析。还可以通过各种参数，来分解每个环节的执行情况。
　　今天的内容就到这里，有哪些想要了解的可以留言告诉我。