MySQL优化从执行计划开始(explain超详细)

Posted Code综艺圈

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了MySQL优化从执行计划开始(explain超详细)相关的知识,希望对你有一定的参考价值。

前言

小伙伴一定遇到过这样反馈:这页面加载数据太慢啦,甚至有的超时了,用户体验极差,需要赶紧优化;

反馈等同于投诉啊,多有几次,估计领导要找你谈话啦。

于是不得不停下手里头的活,赶紧进行排查,最终可能是程序处理的问题、也可能是并发量大导致排队问题、也可能是SQL查询性能导致等;而在很多时候,SQL查询缓慢是最直接拖慢系统的罪魁祸首,同样是实现一个功能,有的小伙伴毫秒级呈现效果,有的却要好几秒,而调优需要的花费时间不容小觑,最终可能就体现到个人业务能力上和形象上:哇,真牛逼,分分钟搞定;菜鸟,居然写出这样的SQL;

而对于SQL调优,搜索引擎一查,72般绝技绝对够秀,于是照着开始实操,运气好一下就解决啦,运气差的时候怎么用都不行;所以更重要的是业务场景,要学会分析原因,最后才知道用什么方式解决;而这个系列就来聊聊数据库优化,聊聊原因,聊聊方法。

1. mysql逻辑结构先知

关于MySQL的逻辑结构,将其理解为四层,就像项目分层一样,每一层处理不同的业务逻辑,先看图后说话:

image-20210313155849571

上图概述:

  • 客户端:这里指连接MySQL各种形式,如.Net中使用的ADO连接、Java使用JDBC连接等;MySQL是客户端和服务器模式,前提先建立连接,才能传输数据,处理相关逻辑;

  • 业务逻辑:在MySQL内部有很多模块组成,分别处理相关业务逻辑;

    连接管理:负责连接认证、连接数判断、连接池处理等业务逻辑处理;

    查询缓存:当一个SQL进来时,如果开启查询缓存功能,MySQL会优先去查询缓存中检查是否有数据匹配,如果匹配上,就不会再去解析对应的SQL啦,但如果语句中有用户自定义函数、存储函数、用户变量、临时表、mysql库中的系统表时,都不会走缓存;对于查询缓存来说,在MySQL8.0已经去除,官方回应的是在一定场景上,查询缓存会导致性能上的瓶颈。

    解析器:对于一个SQL语句,MySql根据语法规则需要对其进行解析,并生成一个内部能识别的解析树;

    优化器:负责对解析器得到的解析树进行优化,MySQL会根据内部算法找到一个MySQL认为最优的执行计划,后续就按照这个执行计划执行。所以后续我们分析的就是MySQL针对SQL语句选择出来的最优执行计划,结合业务,根据规则对SQL进行优化,从而让SQL语句在MySQL内部达到真正的最优。

    执行器:得到执行计划之后,就会找到对应的存储引擎,根据执行计划给出的指令依次执行。

  • 存储引擎:数据的存储和提取最后是靠存储引擎;MySQL内部实现可插拔式的存储引擎机制,不同的存储引擎执行不同的逻辑;

  • 物理文件:数据存储的最终位置,即磁盘上;协同存储引擎对数据进行读写操作。

关于MySql的逻辑结构,以上只是简单描述,业务逻辑层的功能模块远不止上面提到的,小伙伴有兴趣可以专门研究一下,这里的目的就是为了体现SQL语句到服务器上时经过的几个关键步骤,方便后续优化的理解。

2. SQL语句的中关键字执行顺序须知

在编写一条查询语句时,习惯性的从头到尾开始敲出来,应该都是从select 开始吧,但似乎没太注意它们真正的执行顺序;既然要优化,肯定需要得知道一条SQL语句大概的执行流程,结合执行计划,目的就更加清晰啦;上一张一看就明白的图:

MySQL优化从执行计划开始(explain超详细)
image-20210313223002285

关键字简述:

  • FROM:确定数据来源,即指定表;

  • JOIN…ON:确定关联表和关联条件;

  • WHERE:指定过滤条件,过滤出满足条件的数据;

  • GROUP BY:按指定的字段对过滤后的数据进行分组;

  • HAVING:对分组之后的数据指定过滤条件;

  • SELECT:查找想要的字段数据;

  • DISTINCT:针对查找出来的数据进行去重;

  • ORDER BY:对去重后的数据指定字段进行排序;

  • LIMIT:对去重后的数据限制获取到的条数,即分页;

好啦,大概了解MySQL的逻辑结构和SQL查询关键字执行顺序之后,接下来就可以好好说说执行计划啦。

3. 好好说说执行计划

演示用的版本是MySql5.5,各版本之间会有不同,所以小伙伴用的版本测试结果不一样的时候,千万别骂我渣哦;其实重要的是查看的思路,整体是大同小异。(求原谅……)

通过explain会输出如下信息,很多小伙伴只关注红框标注部分(即索引),但其实是不够的,接下来就一个一个好好说说。

MySQL优化从执行计划开始(explain超详细)
image-20210314190432145
  • id

    这个id和咱们平时表结构设计的主键ID不太一样,这里的id代表了每一条SQL语句执行计划中表加载的顺序,分为三种情况:

id相同的时候:这时是从上到下依次执行;

 EXPLAIN SELECT t.ID,t.USER_NAME,r.ROLE_NAME FROM USER t  JOIN USER_ROLE tr ON t.ID = tr.USER_ID JOIN ROLE r ON tr.ROLE_ID = r.ID

执行如下语句,得如下结果:

MySQL优化从执行计划开始(explain超详细)
image-20210315000741898

如上图所示,id一样,从上到下依次执行,所对应表加载顺序为t->tr->r(这里的表是别名);

id不同的时候:当id不同的时,id越大的越先执行;

 EXPLAIN SELECT t.ID,t.MENU_NAME,t.MENU_URL FROM MENU t WHERE t.ID IN (SELECT MENU_ID FROM ROLE_MENU rm  WHERE rm.ROLE_ID IN(SELECT ROLE_ID FROM USER_ROLE ur WHERE ur.USER_ID=1))

子查询会导致id递增,结果如下:

MySQL优化从执行计划开始(explain超详细)
image-20210315002147586

如上图所示,id递增啦,所对应表的加载顺序为ur->rm->t(这里的表是别名);

id相同和不同同时存在时:id相同的认为是同一组,还是从上往下加载;不一样的情况还是越大越优先执行

 EXPLAIN SELECT t.ROLE_ID,m.ID,m.MENU_NAME,m.MENU_URL FROM  (SELECT ROLE_ID FROM USER_ROLE WHERE USER_ID=3) t,ROLE_MENU rm,MENU m WHERE t.ROLE_ID=rm.ROLE_ID AND rm.MENU_ID=m.ID

执行结果如下:

MySQL优化从执行计划开始(explain超详细)
image-20210315004001664

如上图所示,id有一样的,也有不同的,则对应表的加载顺序为USER_ROLE->derived2 (衍生表)->rm->m;衍生表表名后面的2代表的是id,所以可以通过衍生表表名后面的id知道是哪一步产生的,即derived2衍生表是id为2的这一步产生的。

  • select_type

    select_type 是表示每一步的查询类型,方便分析人员很直接的看到当前步骤执行的是什么查询,有多种类型,见下图:

1>  SIMPLE:简单的SELECT查询,不包含子查询或UNION的那种;

 EXPLAIN SELECT * FROM USER;

输出结果如下:

MySQL优化从执行计划开始(explain超详细)
image-20210315124541198

2>  PRIMARY:查询语句中包含其他子查询或UNION操作,那最外层的SELECT就被标记为该类型;

MySQL优化从执行计划开始(explain超详细)
image-20210315124706414

如上图所示,查询中包含子查询,最外层查询被标记为PRIMARY;

3>  SUBQUERY:在SELECT或WHERE中包含的子查询会被标记为该类型;

PRIMARY图,当存在子查询时,会将子查询标记为SUBQUERY

4>  MATERIALIZED:被物化的子查询,即针对对应的子查询将其物化为一个临时表;

EXPLAIN SELECT t.ID,t.MENU_NAME,t.MENU_URL FROM MENU t WHERE t.ID IN (SELECT MENU_ID FROM ROLE_MENU rm  WHERE rm.ROLE_ID IN(SELECT ROLE_ID FROM USER_ROLE ur WHERE ur.USER_ID=1));

测试物化用的是MySQL8.0,和5.*版本有所不同,输出结果如下:

MySQL优化从执行计划开始(explain超详细)
image-20210315125116200

如上图所示,将子查询物化为一个临时表subquery2,这个功能是可以通过设置优化器对应的开关的。

5>  DERIVED:在FROM之后的子查询会被标记为该类型,同样会把结果放在一个临时表中;

 EXPLAIN SELECT tm.MENU_NAME,rm.ROLE_ID FROM  (SELECT * FROM MENU WHERE ID >3 ) tm ,ROLE_MENU rm  WHERE tm.ID=rm.MENU_ID AND rm.ROLE_ID=1

输出结果:

MySQL优化从执行计划开始(explain超详细)
image-20210315205026760

如图所示,FROM后面跟的子查询就被标记为DERIVED,对应步骤产生的衍生表为derived2。高版本好像对其进行了优化,8.0版本这种形式认为是简单查询。

6>  UNION:UNION操作中,查询中处于内层的SELECT;

 EXPLAIN SELECT * FROM USER_ROLE T1 WHERE T1.USER_ID=1 UNION SELECT * FROM USER_ROLE T2 WHERE T2.USER_ID=2

输出结果如下:

MySQL优化从执行计划开始(explain超详细)
image-20210315133138810

如上图所示,将第二个SELECT标注为UNION ,即对应加载的表为T2。

7>  UNIOIN RESULT:UNION操作的结果,对应的id为空,代表的是一个结果集;

UNIOIN图,UNIOIN RESULT代表的是UNION之后的结果,对应id为空。

  • table

    table代表对应步骤加载的是哪张表,中间会出现一些临时表,比如subquery2、derived2等这种,最后的数字代表产生该表对应步骤的id。

  • type

    代表访问类型,MySQL内部将其分为多类型,常用的类型从好到差的顺序展示如下:

    system->const->eq_ef->ref->fulltext->ref_or_null->index_merge->unique_subquery->index_subquery->range->index->ALL;

    而在实际开发场景中,比较常见的几种类型如下:const->eq_ref->ref->range->index->ALL(顺序从好到差),通常优化至少在range级别或以上,比如ref算是比较不错的啦;

    上面说到的从好到差指的是查询性能。

1>const:表示通过索引一次就找到数据,用于比较primary key或者unique索引,很快就能找到对应的数据;

MySQL优化从执行计划开始(explain超详细)
image-20210315213348812

2>eq_ref:唯一性索引扫描,对于每个索引键,表中只有一条记录与之匹配,常用于主键或唯一索引扫描;

MySQL优化从执行计划开始(explain超详细)
image-20210315215246361

3>ref:非唯一索引扫描,返回匹配的所有行,如建立一个朋友维护表,维护用户对应的朋友,而在用户ID建立非唯一索引;

MySQL优化从执行计划开始(explain超详细)
image-20210315220544506

4>range:使用一个索引检索指定范围的行,一般在where语句中会出现between、<、>、in等范围查询;

MySQL优化从执行计划开始(explain超详细)
image-20210315221838825

5>index:全索引扫描,只遍历索引树;

MySQL优化从执行计划开始(explain超详细)
image-20210315222312090

6>ALL:全表扫描,找到匹配行。与index比较,ALL需要扫描磁盘数据,index值需要遍历索引树。

MySQL优化从执行计划开始(explain超详细)
image-20210315222815614
  • possible_keys

    显示可能被用到的索引,但在实际查询中不一定能用到;查询涉及到字段,如果存在索引,会被列出,但如果使用的是覆盖索引,只会在key中列出;

    MySQL优化从执行计划开始(explain超详细)
    image-20210315223744943
  • key

    实际使用到的索引,如果为NULL代表没有使用到索引;这也是平时小伙伴判断是否用上索引的关键。

  • key_len

    key_len表示索引使用的字节数,根据这个值可以判断索引的使用情况,特别是在组合索引的时候,判断该索引有多少部分被使用到,非常重要;key_len是根据表定义计算而得。这里测试在USER表中对USER_NAME创建一个非唯一索引,如下:

    MySQL优化从执行计划开始(explain超详细)
    image-20210316001057900

    这里key_len是这么计算的,前提是指定的字符串集是utf8,可变长 且允许为空,计算过程如下:

    128(设置的可变长度)*3(utf8占3字节)+1(允许为空标识占一个字节)+2(长度信息占两个字节)=387;

    key_len针对不同类型字段的计算规则不一样,这里用USER(用户表)简单计算为例:

    字段 Key_len 说明
    ID(int,不为空) 4 int为4个字节,不为空
    USER_NAME(varchar(128),utf8,可为空) 128*3+1+2=387 可变为128,utf8每个占3字节,1个字节标识可控,两个字节标识长度

    不同类型占用的字节不一样,字符集不一样占用的字节也不一样,允许为空的字段需要1个字节做标识,可变长度的字段需要2个字节标识长度。小伙伴照着这个思路就可以计算其他类型啦。

  • ref

    显示索引的哪些列被引用了,通常是对应字段或const;

    MySQL优化从执行计划开始(explain超详细)
    image-20210316003104264
    MySQL优化从执行计划开始(explain超详细)
    image-20210316003227737
  • rows

    根据表统计信息和索引的使用情况,大概估算出找到所需记录数据所扫描的数据行数;不是所需数据的行数。

  • Extra

    这个字段里包含一些其他信息,但也是优化SQL的重要参考,通常会出现以下几种信息:

Using index:表示查询语句中用到了覆盖索引,不访问表的数据行,查询效率比较好。

MySQL优化从执行计划开始(explain超详细)
image-20210316092530361

如果用SELECT *进行查询,就不会有Using index,关于索引的介绍下篇好好说说。

Using filesort:代表MySQL会使用一个外部索引对数据进行排序(文件排序),而不是使用表内索引。这种情况在SQL查询需要避免,最好不要在Extra中出现此类型:

MySQL优化从执行计划开始(explain超详细)
image-20210316093336121

通常会是使用ORDER BY语句导致,上图中使用无索引的字段进行排序会出现,同样如果使用有索引的字段,但用法不对也会出现,比如使用组合索引不规范时。

Using temporary:产生临时表保存中间结果,这种SQL是不允许的,遇见数据量大的场景,基本就跑不动啦;

MySQL优化从执行计划开始(explain超详细)
image-20210316094004777

这种类型常常因为ORDER BY 和 GROUP BY导致,所以在进行数据排序和分组查询时,要注意索引的合理利用。

Using where:使用where过滤数据,小伙伴试一把。

Using join buffer:表示使用到了表连接缓存;当表数据量大,可能导致buffer过大,查询效率比较低,这种情况注意在表连接字段上正确使用索引。

MySQL优化从执行计划开始(explain超详细)
image-20210316101458370

如果表连接查询慢时,在连接字段上加个索引试试,药到病除;

impossible where:代表where后面的条件永远为false,匹配不到数据;

image-20210316095219041

用到的表及数据从Gitgub中获取:https://github.com/zyq025/SQL_Optimize

总结

看完这篇文章之后,小伙伴再去找些SQL看看对应的执行计划,是不是看懂啦,对于优化意义非凡;但是这还不够,接下来还要聊聊索引,聊聊索引失效情况,聊聊除了EXPALIN其他优化方式等,最后日常的开发优化应该都能搞定,远离低效SQL,是不是又有更多时间学习啦。

一个被程序搞丑的帅小伙,关注"Code综艺圈",跟我一起学~~~

图片


以上是关于MySQL优化从执行计划开始(explain超详细)的主要内容,如果未能解决你的问题,请参考以下文章

MySql查询优化-执行计划explain详细说明

MySQL性能优化:EXPLAIN 执行计划与join

MySQL性能优化:EXPLAIN 执行计划与join

Mysql(21)—EXPLAIN执行计划的字段详解

mysql 执行计划explain详解

MySQL之性能优化