MySQL慢查询优化之慢查询日志分析的实例教程

MySQL慢查询优化之慢查询日志分析的实例教程_MySQL

php中文网

发布： 2016-05-27 13:45:45

原创

893人浏览过

数据库响应慢问题最多的就是查询了。现在大部分数据库都提供了性能分析的帮助手段。例如oracle中会帮你直接找出慢的语句，并且提供优化方案。在mysql中就要自己开启慢日志记录加以分析（记录可以保存在表或者文件中，默认是保存在文件中，我们系统使用的就是默认方式）。

先看看MySQL慢查询日志里面的记录长什么样的：

Time         Id Command  Argument
# Time: 141010 9:33:57
# User@Host: root[root] @ localhost [] Id:   1
# Query_time: 0.000342 Lock_time: 0.000142 Rows_sent: 3 Rows_examined: 3
use test;
SET timestamp=1412904837;
select * from t;

登录后复制

这个日志应该很好理解了，第一个#记录时间戳，第二个#记录执行命令的用户和地址信息，第三个#记录执行查询的时间、锁的时间、返回行数、被扫描的行数。接着后面记录真正执行的SQL语句。还可以通过以下命令看看cvs存储格式每个字段意义。

SHOW CREATE TABLE mysql.slow_log;

登录后复制

接下来说说如何获取和分析慢日志吧。

查看MySQL慢日志参数

进入启动好的MySQL，执行以下命令

mysql> show variables like '%slow_query%';

登录后复制

+---------------------------+----------------------------------------+
| Variable_name       | Value                 |
+---------------------------+----------------------------------------+
| slow_query_log      | OFF                  |
| slow_query_log_file    | /usr/local/mysql/data/cloudlu-slow.log |
+---------------------------+----------------------------------------+

登录后复制

这里告诉我们慢日志的日志存放位置，慢日志是否有开启。
那么什么样的查询需要被日志呢？在MySQL中，没有index的查询以及超过指定时间同时超过指定扫描行数的查询需要记录在慢日志查询里面。

那么它们的参数又是怎么查看的呢？

没有index的查询记录开关

mysql> show global variables like '%indexes%';

登录后复制

+----------------------------------------+-------+
| Variable_name             | Value |
+----------------------------------------+-------+
| log_queries_not_using_indexes     | OFF  |
| log_throttle_queries_not_using_indexes | 0   |
+----------------------------------------+-------+

登录后复制

第一个参数表示是否开启记录没有index的查询，第二个

参数用来做日志记录的流量控制，一分钟可以记录多少条，默认0是表示不限制。

超过指定时长的查询开关

mysql> show global variables like '%long_query%';

登录后复制

+-----------------+-----------+
| Variable_name  | Value   |
+-----------------+-----------+
| long_query_time | 10.000000 |
+-----------------+-----------+
1 row in set (0.00 sec)

登录后复制

就一个参数指定超过多少时长的查询需要被记录

超过指定行数的扫描查询开关

mysql> show variables like '%min_examined_row_limit%';

登录后复制

+------------------------+-------+
| Variable_name     | Value |
+------------------------+-------+
| min_examined_row_limit | 0   |
+------------------------+-------+
1 row in set (0.00 sec)

登录后复制

默认是0，代表不现在扫描行数

设置开启MySQL慢日志参数

进入MySQL，输入以下命令或者在MySQL的启动配置文件里面修改或者给MySQL添加启动参数，进入MySQL后的修改如下：

set global long_query_time=0.1;
set global log_queries_not_using_indexes=on;
set global slow_query_log = on;

登录后复制

这里要斟酌的有2点，第一是超过什么时长的日志是有问题的，这个由系统需求来决定。第二是没有使用indexes的日志每分钟要记录多少条，要防止日志太多对性能产生影响。

在实际的日志分析中，通常慢日志的log数量不少，同时相同的查询被记录的条数也会很多，这里就需要如何从慢日志查询中找到最有问题，最需要优化的日志。在这方面，有很多分析工具，最基本的分析工具就是MySQL自带的mysqldumpslow，mysqldumpslow(Perl脚本)的输出示例：

[root@cloudlu bin]# ./mysqldumpslow -s t -t 1 /usr/local/mysql/data/cloudlu-slow.log

登录后复制

Reading mysql slow query log from /usr/local/mysql/data/cloudlu-slow.log 
Count: 1 Time=0.00s (0s) Lock=0.00s (0s) Rows=3.0 (3), root[root]@localhost 
 select * from t

登录后复制

一看就非常清楚，它的输出主要统计不同慢sql的出现次数(Count 1)，执行最长时间(Time 0.00s)，累计总耗费时间(Time 0s)，等待锁的时间(Lock 0.00s)，等待锁的总时间(Lock 0s)，发送给客户端的行总数(Rows 3.0)，扫描的行总数(Rows 3)，用户(root)以及sql语句本身。它最常用的参数包括：

-s 排序选项：c 查询次数 r 返回记录行数 t 查询时间
-t n：显示top n条查询

对于一般的分析已经差不多了，不过对于百分比等等数据mysqldumpslow就不够完善了。所以世界上多了很多各种MySQL慢日志分析工具，比较优秀的有mysqlsla(Perl脚本)和pt-query-digest(Perl脚本)，可以提供Count, sql的执行次数及占总的slow log数量的百分比，Time, 执行时间, 包括总时间, 平均时间, 最小, 最大时间, 时间占到总慢sql时间的百分比，95% of Time, 去除最快和最慢的sql, 覆盖率占95%的sql的执行时间，Lock Time, 等待锁的时间，95% of Lock , 95%的慢sql等待锁时间，Rows sent, 结果行统计数量, 包括平均, 最小, 最大数量，Rows examined, 扫描的行数量，还可以生成表报，存储分析结果。这里就不一一介绍了。

通过这些慢日志分析软件定位到了慢查询语句就已经完成了SQL优化的一大半。接下来通过在MySQL中执行explain或者desc命令查看慢查询语句，可以看出为什么SQL查询慢。

mysql> explain select * from test.t \G

登录后复制

*************************** 1. row *************************** 
      id: 1 
 select_type: SIMPLE 
    table: t 
     type: ALL 
possible_keys: NULL 
     key: NULL 
   key_len: NULL 
     ref: NULL 
     rows: 2 
    Extra: NULL 
1 row in set (0.00 sec)

登录后复制

它的输出格式细节可以关注MySQL explain format，在输出中最要注意的是：
1. type：ALL是效率最差，最要注意的

2. key：是否有使用Key，key长度如何

3. Extra：最好不要出现filesort以及temporary，最主要是要关注在orderby和groupby。

Note: SQL优化是个很复杂的过程，有可能出现拆东墙补西墙的情况：比如给数据库表加入了索引之后，确实查询快了，可是存储空间加多了，插入删除操作耗时也增加了，如果在一个写多读少的系统中，执行这种优化可能会起到反效果。所以优化完之后千万不能大意，要持续监控系统，防止出现引入新瓶颈的情况。