小蚂蚁学习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;    

发生这种状况的缘由，多是发送的sql语句太长，以致于超过了max_allowed_packet的大小，若是确认是这种缘由，只要修改my.cnf，加大max_allowed_packet的值便可。

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 上。