小蚂蚁学习mysql性能优化（3）--SQL以及索引优化--慢查日志分析工具和explain说明

昨天在测试操作数据库的时候碰到两个问题忘了记录下来，今天补充上去，接上篇

1. 安装测试数据库sakila时报错。Mysql server has gone away的问题。解决方法：

查看    show global variables like ‘max_allowed_packet‘;

一般来说会显示    max_allowed_packet    1048576

修改为    set global max_allowed_packet    =    1024*1024*16;    问题解决。不要问我为什么，我也不知道    T_T

2. 我用 mysql 版本   5.6.*  在设置long_query_time的时候，一直修改不了，不生效。在网上查询了一下资料，经过自己测试，这估计是个bug吧，其实已经修改成功了。可以另外打开一个mysql控制台，再查看，就会显示正确。

这是昨天碰到的两个问题，在这里补充一下。

慢查日志的分析工具

mysqldumpslow  安装mysql的时候系统自带。最常用，但是功能不是很完善。

例子：mysqldumpslow -t 3 慢查日志路径 | more

分析慢查日志最耗时的前三条。

pt_query_digest    推荐这一款比较完善的工具

examine 单词 检查  rows examine  扫描的行数

如何通过慢查日志发现有问题的SQL？

1. 查询次数多并且每次查询占用时间长的SQL，通常为pt_query_digest分析的前几个查询。

2. IO大的SQL。注意pt_query_digest分析中的Rows examine项。

未命中索引的SQL。

注意pt_query_digest分析中的这两项的对比    rows examine 和 rows send  扫描行数和发送行数

如果rows examine 远远大于rows send的话，说明未命中。

找到非常耗时sql之后，如何分析，使用explain，explain返回各列的含义

    table:    显示这一行的数据时关于哪张表

    type:    重要列！！显示了连接使用了何种类型。从最好到最差的连接类型为const、eq_reg、reg、range、index    和 all。

    possible_keys:    显示可能应用在这张表中的索引。如果为空，没有可能的索引。

    key：    实际使用的索引。如果为null，则没有使用索引。

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

    ref:    显示索引的哪一个列被使用了，如果可能的话，是一个常数

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

    extra:    需要注意的返回值（扩展列）

            using filesort : 看到这个的时候，查询就需要优化。mysql需要进行额外的步骤来发现如何对返回的行排序。它根据链接类型以及存储排序键值和匹配条件的全部行的行指针来排序全部行。

            using temporary : 看到这个的时候，查询需要优化。mysql需要创建一个临时表来存储结果，这通常发生在对不同的列集进行order by上，而不是group by 上。

小蚂蚁学习mysql性能优化（3）--SQL以及索引优化--慢查日志分析工具和explain说明

标签：