本文提要

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

优化步骤

总结了一下，大致步骤如下：

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

找出慢sql

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

慢sql监控

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

慢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

结果集说明如下：

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

优化目标

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

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

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

优化

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

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

ssm_article

ssm_picture

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

ssm_book

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

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

ssm_book

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

ssm_picture

ssm_article

type由all全部变为index。

总结

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