视频1 视频21 视频41 视频61 视频文章1 视频文章21 视频文章41 视频文章61 推荐1 推荐3 推荐5 推荐7 推荐9 推荐11 推荐13 推荐15 推荐17 推荐19 推荐21 推荐23 推荐25 推荐27 推荐29 推荐31 推荐33 推荐35 推荐37 推荐39 推荐41 推荐43 推荐45 推荐47 推荐49 关键词1 关键词101 关键词201 关键词301 关键词401 关键词501 关键词601 关键词701 关键词801 关键词901 关键词1001 关键词1101 关键词1201 关键词1301 关键词1401 关键词1501 关键词1601 关键词1701 关键词1801 关键词1901 视频扩展1 视频扩展6 视频扩展11 视频扩展16 文章1 文章201 文章401 文章601 文章801 文章1001 资讯1 资讯501 资讯1001 资讯1501 标签1 标签501 标签1001 关键词1 关键词501 关键词1001 关键词1501 专题2001
MySQL慢查询优化之慢查询日志分析的实例教程_MySQL
2020-11-09 20:17:00 责编:小采
文档


数据库响应慢问题最多的就是查询了。现在大部分数据库都提供了性能分析的帮助手段。例如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优化是个很复杂的过程,有可能出现拆东墙补西墙的情况:比如给数据库表加入了索引之后,确实查询快了,可是存储空间加多了,插入删除操作耗时也增加了,如果在一个写多读少的系统中,执行这种优化可能会起到反效果。所以优化完之后千万不能大意,要持续监控系统,防止出现引入新瓶颈的情况。

    下载本文
    显示全文
    专题