首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >Spring+SpringMVC+MyBatis+easyUI整合优化篇(十二)数据层优化-explain关键字及慢sql优化

Spring+SpringMVC+MyBatis+easyUI整合优化篇(十二)数据层优化-explain关键字及慢sql优化

作者头像
程序员十三
发布2018-03-15 14:51:45
1.2K0
发布2018-03-15 14:51:45
举报
文章被收录于专栏:程序员有故事程序员有故事

本文提要

从编码角度来优化数据层的话,我首先会去查一下项目中运行的sql语句,定位到瓶颈是否出现在这里,首先去优化sql语句,而慢sql就是其中的主要优化对象,对于慢sql,顾名思义就是花费较多执行时间的语句,它带来的影响也比较恶劣,首先是执行时间过长影响数据的返回速度,其次,慢sql的长时间执行也会消耗和占用mysql的系统资源,影响其他的sql语句执行,过多的慢sql极其影响性能,如果系统流量或者并发量较大的情况下,过多的执行慢sql很有可能造成mysql的死锁以致于mysql服务无法正常使用。 druid整合到项目中以及druid监控的开启已经持续了一段时间,因此对于慢sql的监控和整理也大致有了一些结果,本篇文章就试着从日志文件和监控面板中找出几条慢sql并进行优化。

优化步骤

总结了一下,大致步骤如下:

  • 定位优化对象的性能瓶颈;
  • 明确优化目标;
  • 从explain入手分析;
  • 找到优化方法;

找出慢sql

首先进入druid监控后台,查看一下这几天的运行日志后,慢sql的大致情况,如图:

慢sql监控
慢sql监控

从监控后台看到的数据只是一个粗略的统计,是一个总览记录,想要看到详细的执行记录及其中的慢sql统计可以通过日志文件,这个功能也已经整合到项目中,直接在tomcat的logs目录即可查看。

慢sql日志文件
慢sql日志文件

日志文件内容节选:

//1.图片表查询sql
[10:13:37] StatFilter - slow sql 1572 millis. 
select * from ssm_picture
         WHERE  type = ? and grade = ?          
 limit ?,?
["1","1",0,10]

...
//2.更新文章表sql
[14:19:12] StatFilter - slow sql 1926 millis. 
update ssm_article
        set
        article_title=?,article_content=?,
        add_name=?
        where id=?
["11","<p>1324354657usdfghjnkm,zxvb nm,,fgfhjtfggggggggggggggggggg<br/></p>","22","1033"]

...

//3.文章表查询sql
[15:07:04] StatFilter - slow sql 1672 millis. 
select * from ssm_article
limit ?,?
[0,10]

日志的记录格式为 [执行时间] -慢sql执行耗时 ,sql语句,其实日志中记录是挺多的,去重之后从日志文件中单独选了几条比较典型的sql语句进行优化。

explain关键字

explain关键字一般放在SELECT查询语句的前面,用于描述MySQL如何执行查询操作、以及MySQL成功返回结果集需要执行的行数。explain 可以帮助我们分析 select 语句,让我们知道查询效率低下的原因,从而改进我们查询,让查询优化器能够更好的工作。

用法:

explain-01
explain-01

结果集说明如下:

说明

id

MySQL Query Optimizer选定的执行计划中查询的序列号。表示查询中执行select子句或操作表的顺序,id值越大优先级越高,越先被执行。id相同,执行顺序由上至下。

select_type 查询类型

说明

SIMPLE

简单的select查询,不使用union及子查询。

PRIMARY

最外层的select查询。

UNION

UNION 中的第二个或随后的 select查询,不依赖于外部查询的结果集。

DEPENDENT UNION

UNION中的第二个或随后的 select查询,依 赖于外部查询的结果集。

SUBQUERY

子查询中的第一个select查询,不依赖于外部查询的结果集。

DEPENDENT SUBQUERY

子查询中的第一个select查询,依赖于外部查询的结果集。

DERIVED

用于from子句里有子查询的情况。MySQL会递归执行这些子查询,把结果放在临时表里。

UNCACHEABLE SUBQUERY

结果集不能被缓存的子查询,必须重新为外层查询的每一行进行评估。

UNCACHEABLE UNION

UNION中的第二个或随后的select查询,属于不可缓存的子查询。

说明

table

输出行所引用的表

type 显示连接使用的类型,按最优到最差的类型排序

说明

system

表仅有一行(=系统表)。这是const连接类型的一个特例。

const

const用于用常数值比较PRIMARY KEY时。当查询的表仅有一行时,使用System。

eq_ref

const用于用常数值比较PRIMARY KEY时。当查询的表仅有一行时,使用System。

ref

连接不能基于关键字选择单个行,可能查找到多个符合条件的行。叫做ref是因为索引要跟某个参考值相比较。这个参考值或者是一个常数,或者是来自一个表里的多表查询的结果值

ref_or_null

如同ref, 但是MySQL必须在初次查找的结果里找出null条目,然后进行二次查找。

index_merge

说明索引合并优化被使用了。

unique_subquery

在某些IN查询中使用此种类型,而不是常规的ref:value IN (SELECT primary_key FROM single_table WHERE some_expr)

index_subquery

在某些IN查询中使用此种类型,与unique_subquery类似,但是查询的是非唯一性索引:value IN(SELECT key_column FROM single_table WHERE some_expr)

range

只检索给定范围的行,使用一个索引来选择行。key列显示使用了哪个索引。当使用=、<>、>、>=、<、<=、IS NULL、<=>、BETWEEN或者IN操作符,用常量比较关键字列时,可以使用range。

index

全表扫描,只是扫描表的时候按照索引次序进行而不是行。主要优点就是避免了排序,但是开销仍然非常大。

all

最坏的情况,从头到尾全表扫描。

说明

possible_keys

指出MySQL能在该表中使用哪些索引有助于查询。如果为空,说明没有可用的索引。

说明

key

MySQL实际从possible_key选择使用的索引。如果为NULL,则没有使用索引。很少的情况下,MYSQL 会选择优化不足的索引。这种情况下,可以在SELECT语句中使用USE INDEX (indexname)来强制使用一个索引或者用IGNORE INDEX(indexname)来强制MYSQL忽略索引

说明

key_len

使用的索引的长度。在不损失精确性的情况下,长度越短越好。

说明

ref

显示索引的哪一列被使用了

说明

rows

MYSQL认为必须检查的用来返回请求数据的行数

extra 中出现以下2项意味着MYSQL根本不能使用索引,效率会受到重大影响。应尽可能对此进行优化。

extra项

说明

Using filesort

表示MySQL会对结果使用一个外部索引排序,而不是从表里按索引次序读到相关内容。可能在内存或者磁盘上进行排序。MySQL中无法利用索引完成的排序操作称为“文件排序”

Using temporary

表示MySQL在对查询结果排序时使用临时表。常见于排序order by和分组查询 group by。

优化目标

优化的目标是一定要明确的,不然根本无从下手,针对于前文中提到的sql语句,及explain关键字的解释,我列出了两条目标:

  • 避免全表扫描
  • rows参数尽量减小

至于为什么只列出这两条目标,主要是因为项目中并没有复杂的逻辑,也也没有复杂的查询,建表时也并没有根据相关查询创建索引,而且数据量也不大,因此能够优化的点并不是太多,即使做了优化也不能显著的提升速度及性能,因此就先列了两个简单的小目标,先体验一下explain关键字在sql优化中的作用。

优化

针对第2条更新文章sql,执行时间较长的原因主要是因为数据量太大,应该是一个朋友在测试的时候做的操作,article_content字段插入了一条20万字符大小的数据,因此,主要问题在于插入数据过大,代码已经更新了参数检查功能,在程序中做了限制。

对于另外两条查询语句,首先用explain分析sql语句,如下:

ssm_article
ssm_article
ssm_picture
ssm_picture

注意其中的两个参数,type都是all,rows较小,都为总记录,我们的两个目标是什么?type不能为all,rows尽量小,这里似乎满足了一个条件,其实不然,因为这两个表的数据量小,因此rows值也小,如果换一张表(book表较大),以相同格式执行一条sql得到如下结果:

ssm_book
ssm_book

rows为416,并没有因为使用了limit关键字而返回较小的值,因此两条sql都需要做一下简单的优化。

几张表都没有创建索引,是不是就没有索引了呢?其实不然,你可能忽略了一点,就是主键索引,索引的知识点在接下来一篇文章中会写,这一篇就简单的提一下,因此优化策略就是使用主键索引,将type由all变为index,稍微优化了一点点,改写后的sql语句如下,分析结果如下:

ssm_book
ssm_book

通过与上面的结果对比,可以看到rows值也变小了。

ssm_picture
ssm_picture
ssm_article
ssm_article

type由all全部变为index。

总结

由于项目比较简单,都是操作单表的sql语句,没有复杂查询,也没有多表的连接查询,速度提升并没有太多,对于目前的项目来说,不会有特别大的优化动作,如果以后有机会再去结合实际案例去优化,现在就点到为止了,这一篇主要是介绍一下druid监控的成果以及mysql查询优化的explain关键字,因此并没有做太多的案例及分析,只是做了一些小修改,使得大家对explain关键字有了一些了解,下一篇会继续做一些优化改动。

本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 本文提要
  • 优化步骤
  • 找出慢sql
  • explain关键字
  • 优化目标
  • 优化
  • 总结
相关产品与服务
云数据库 MySQL
腾讯云数据库 MySQL(TencentDB for MySQL)为用户提供安全可靠,性能卓越、易于维护的企业级云数据库服务。其具备6大企业级特性,包括企业级定制内核、企业级高可用、企业级高可靠、企业级安全、企业级扩展以及企业级智能运维。通过使用腾讯云数据库 MySQL,可实现分钟级别的数据库部署、弹性扩展以及全自动化的运维管理,不仅经济实惠,而且稳定可靠,易于运维。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档