前言
前段时间接手库房项目之后，有很多地方需要优化，从中也学到了很多东西，将在博客中一一整理出来分享给大家。
实际案例：库房系统中管理员权限下的入库管理中的入库记录页面每次打开时都加载的非常慢，长达三十多秒，网速慢的时候会达到一分钟左右，这个问题非常影响库房系统的功能使用，首先需要解决的就是这个问题。最后我们找到了问题所在，原来是D层下的SQL语句的问题，查询速率快慢和SQL语句的查询顺序密切相关，想必大家在软考中也做过类似的题，除此之外还可以通过建索引来提高查询速度，还有一种方法就是写一个接口。
正文
1、数据库优化的目的
避免出现页面访问错误：
- 由于数据库连接timeout产生页面5xx错误
- 由于慢查询造成页面无法加载
- 由于阻塞造成数据无法提交
增加数据库的稳定性：
- 很多数据库问题都是由于低效的查询引起的
优化用户体验：
- 流畅页面的访问速度
- 良好的网站功能体验
可以从几个方面进行数据库优化：
2、SQL及索引优化
慢查日志的分析工具：
- 输出到文件：pt-query-digest slow-log > slow_log.report
- 输出到数据库表：
pt-query-digest slow.log -review\
h=127.0.0.1,D=test,p=root,P=3306,u=root,t=query_review\
--create-reviewtable\
--review-history t=hostname_slow
慢查日志的分析工具——pt-query-digest输出：
3、如何通过慢查日志发现有问题的SQL？
1、查询次数多且每次查询占用时间长的SQL
通常为pt-query-digest分析的前几个查询
2、IO大的SQL
注意pt-query-digest分析中的rows examine项
3、未命中索引的SQL
注意pt-query-digest 分析中rows examine和rows send的对比
4、使用explain查询SQL的执行计划
案例：在Navicat Premium中展示一个explain的具体使用效果：
如何 分析SQL查询，下面解释explain返回各列的含义：
table：显示这一行的数据是关于哪张表的
type：这一列很重要，显示连接使用了何种类型。从最好到最差的连接类型为const，eq_reg,ref,range,index ,ALL
possible_keys：显示可能应用在这张表中的索引。如果为空，没有可能的索引。
key：实际使用的索引。如果为NULL，则没有使用索引。
key_len:使用的索引的长度。在不损失精确性的情况下，长度越短越好。
ref：显示索引的哪一列被使用了，如果可能的话，是一个常数。
rows:MySQL认为必须检查的用来返回请求数据的行数。
extra列需要注意的返回值：
1、Using filesort：看到这个的时候，查询就需要优化了。MySQL需要进行额外的步骤来发现如何对返回的行排序。它会根据连接类型以及存储排序键值和匹配条件的全部行的行指针来排序全部行。
2、Using temporary：看到这个的时候，查询需要优化。MySQL需要创建一个临时表来存储结果，通常发生在不同的列集进行ORDER BY上，而不是GROUP BY上。