MySQL优化之慢查询日志
慢查询日志概述
所谓慢查询日志，就是用于记录MySQL中响应时间超过设定阈值的SQL语句，通过打开慢查询开关，MySQL会将大于阈值的SQL记录在日志中，以便于分析性能。
慢查询日志选项默认是关闭的，如果要开启，则需要手动设置。
慢查询日志选项不建议一直开启，因为记录日志意味着IO操作，本身对性能有一定的影响，因此，建议在生产环境关闭该选项；而在开发环境调优阶段可以适当打开该选项。
检查是否开启了慢查询日志：
mysql> show variables like '%slow_query_log%';
+---------------------+-----------------------------------------+
| Variable_name | Value |
+---------------------+-----------------------------------------+
| slow_query_log | OFF |
| slow_query_log_file | /var/lib/mysql/DESKTOP-Q5J25HR-slow.log |
+---------------------+-----------------------------------------+
2 rows in set (0.03 sec)
slow_query_log选项即开启慢查询的开关，OFF为关闭，ON为开启。
slow_query_log_file即慢查询日志的名称。
如果要开启慢查询日志，则执行如下语句：
set global slow_query_log = ON;
/* 或者 */
set global slow_query_log = 1;
以上两句话是一个意思，执行任意一条都可以。执行完毕，再次查询，已经打开。
mysql> set global slow_query_log = ON;
Query OK, 0 rows affected (0.05 sec)
mysql> show variables like '%slow_query_log%';
+---------------------+-----------------------------------------+
| Variable_name | Value |
+---------------------+-----------------------------------------+
| slow_query_log | ON |
| slow_query_log_file | /var/lib/mysql/DESKTOP-Q5J25HR-slow.log |
+---------------------+-----------------------------------------+
2 rows in set (0.00 sec)
同样的，慢查询日志的文件名也可以重新指定，只需要设置set global slow_query_log_file = 文件名即可。
前面说过，慢查询日志只有当SQL语句响应时间超过一定阈值才会记录在日志中，那么这个阈值是多少，该如何设置呢？
可通过以下命令查看慢查询日志的阈值：
mysql> show variables like '%long_query_time%';
+-----------------+-----------+
| Variable_name | Value |
+-----------------+-----------+
| long_query_time | 10.000000 |
+-----------------+-----------+
1 row in set (0.00 sec)
可以看到，默认的阈值是10秒，该值同样可以通过设置来修改，如设置为0.1秒：
set global long_query_time = 0.1;
long_query_time设置完成后，需要退出MySQL客户端，重新登录后才生效，于是可以看到该值已经变成了0.1：
mysql> show variables like '%long_query_time%';
+-----------------+----------+
| Variable_name | Value |
+-----------------+----------+
| long_query_time | 0.100000 |
+-----------------+----------+
1 row in set (0.01 sec)
慢查询日志具体案例
接下来通过案例的方式来演示慢查询日志：
我在当前数据库里有一张test01表，表结构如下所示：
mysql> desc test01;
+--------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+--------+-------------+------+-----+---------+-------+
| id | int(4) | YES | MUL | NULL | |
| name | varchar(20) | YES | | NULL | |
| passwd | char(20) | YES | | NULL | |
| inf | char(50) | YES | | NULL | |
+--------+-------------+------+-----+---------+-------+
4 rows in set (0.04 sec)
分别做如下查询：
select * from test01;
select sleep(1);
select id, sleep(2) from test01;
执行结果如下所示：
mysql> select * from test01;
+------+------+--------+--------+
| id | name | passwd | inf |
+------+------+--------+--------+
| 1 | zz | 123456 | asdfgh |
+------+------+--------+--------+
1 row in set (0.00 sec)
mysql> select sleep(1);
+----------+
| sleep(1) |
+----------+
| 0 |
+----------+
1 row in set (1.00 sec)
mysql> select id, sleep(2) from test01;
+------+----------+
| id | sleep(2) |
+------+----------+
| 1 | 0 |
+------+----------+
1 row in set (2.00 sec)
此时并需要去不关心SQL本身，而是看这三条SQL执行的时间，从上面可以看到，第一条SQL执行几乎不耗时间，显示0.00 sec，第二条SQL显示时间为 1.00 sec，第三条SQL为 2.00 sec。
因为我们设置了阈值为0.1秒，因此后两条SQL应该都要记录在慢查询日志中，接下来验证是否如此：
通过如下命令，可查看慢查询SQL的条数：
mysql> show global status like '%slow_queries%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Slow_queries | 2 |
+---------------+-------+
1 row in set (0.02 sec)
显示记录为2条，与实际情况一致。
通过show variables like '%slow_query_log%'命令，可以查看到日志的具体路径。
mysql> show variables like '%slow_query_log%';
+---------------------+-----------------------------------------+
| Variable_name | Value |
+---------------------+-----------------------------------------+
| slow_query_log | ON |
| slow_query_log_file | /var/lib/mysql/DESKTOP-Q5J25HR-slow.log |
+---------------------+-----------------------------------------+
2 rows in set (0.00 sec)
打开/var/lib/mysql/DESKTOP-Q5J25HR-slow.log，可以看到日志当中记录了时间超过阈值的那两条SQL语句：
/usr/sbin/mysqld, Version: 5.7.29-0ubuntu0.18.04.1 ((Ubuntu)). started with:
Tcp port: 3306 Unix socket: /var/run/mysqld/mysqld.sock
Time Id Command Argument
/usr/sbin/mysqld, Version: 5.7.29-0ubuntu0.18.04.1 ((Ubuntu)). started with:
Tcp port: 3306 Unix socket: /var/run/mysqld/mysqld.sock
Time Id Command Argument
# Time: 2020-03-31T13:41:25.726554Z
# User@Host: root[root] @ localhost [] Id: 6
# Query_time: 1.000644 Lock_time: 0.000000 Rows_sent: 1 Rows_examined: 0
use testDB;
SET timestamp=1585662085;
select sleep(1);
# Time: 2020-03-31T13:41:34.246770Z
# User@Host: root[root] @ localhost [] Id: 6
# Query_time: 2.000536 Lock_time: 0.000057 Rows_sent: 1 Rows_examined: 1
SET timestamp=1585662094;
select id, sleep(2) from test01;
mysqldumpslow工具
以上介绍的方法虽然可以查看出所有慢SQL语句，但显然都记录在一个日志文件里，会显得很乱，而且一旦SQL比较多，定位起来还是比较麻烦的。
好在MySQL本身提供了一个专门用来查看慢查询日志的工具，即mysqldumpslow。
可通过MySQLdumpslow -help查看具体使用方法：
chenyc@DESKTOP-Q5J25HR:~$ mysqldumpslow -help
Usage: mysqldumpslow [ OPTS... ] [ LOGS... ]
Parse and summarize the MySQL slow query log. Options are
--verbose verbose
--debug debug
--help write this text to standard output
-v verbose
-d debug
-s ORDER what to sort by (al, at, ar, c, l, r, t), 'at' is default
al: average lock time
ar: average rows sent
at: average query time
c: count
l: lock time
r: rows sent
t: query time
-r reverse the sort order (largest last instead of first)
-t NUM just show the top n queries
-a don't abstract all numbers to N and strings to 'S'
-n NUM abstract numbers with at least n digits within names
-g PATTERN grep: only consider stmts that include this string
-h HOSTNAME hostname of db server for *-slow.log filename (can be wildcard),
default is '*', i.e. match all
-i NAME name of server instance (if using mysql.server startup script)
-l don't subtract lock time from total time
从以上文件中，可以知道，该工具用法如下：
mysqldumpslow [选项] [日志名]
常用选项说明：
- -s 即order排序,后面可以有以下选项：
- al 平均锁定时间
- ar 平均返回记录时间
- at 平均查询时间
- c 计数
- l 锁定时间
- r 逆序排序
- t 查询时间
- -t，相当于top n，即返回前面n条语句
- -g， 匹配正则表达式，大小写不敏感
如：
sudo mysqldumpslow -s r -t 3 -g 'select' /var/lib/mysql/DESKTOP-Q5J25HR-slow.log
以上命令表示：返回按逆序排序的其中三条语句，且语句中包含select的SQL语句。
结果如下所示：
chenyc@DESKTOP-Q5J25HR:~$ sudo mysqldumpslow -s r -t 3 -g 'select' /var/lib/mysql/DESKTOP-Q5J25HR-slow.log
Reading mysql slow query log from /var/lib/mysql/DESKTOP-Q5J25HR-slow.log
Count: 1 Time=2.00s (2s) Lock=0.00s (0s) Rows=1.0 (1), root[root]@localhost
select id, sleep(N) from test01
Count: 1 Time=1.00s (1s) Lock=0.00s (0s) Rows=1.0 (1), root[root]@localhost
select sleep(N)
Died at /usr/bin/mysqldumpslow line 167, <> chunk 2.
Profiles工具
profiles最大的作用是用来分析海量数据，该命令会记录所有执行过的SQL语句。
这个选项默认也是关闭的，需要手动打开。
查询profiles选项命令：
mysql> show variables like '%profiling%';
+------------------------+-------+
| Variable_name | Value |
+------------------------+-------+
| have_profiling | YES |
| profiling | OFF |
| profiling_history_size | 15 |
+------------------------+-------+
3 rows in set (0.01 sec)
打开命令：
mysql> set profiling = ON;
Query OK, 0 rows affected, 1 warning (0.00 sec)
再次查看，可以换一种方式查看：
mysql> select @@profiling;
+-------------+
| @@profiling |
+-------------+
| 1 |
+-------------+
1 row in set, 1 warning (0.00 sec)
以上选项，1代表打开，0代表关闭。
为了更为直观的查看profile，我们再执行两条SQL：
mysql> select sleep(3);
+----------+
| sleep(3) |
+----------+
| 0 |
+----------+
1 row in set (3.00 sec)
mysql> select * from test01;
+------+------+--------+--------+
| id | name | passwd | inf |
+------+------+--------+--------+
| 1 | zz | 123456 | asdfgh |
+------+------+--------+--------+
1 row in set (0.00 sec)
好了，准备工作就到这里，现在来查看profile：
mysql> show profiles;
+----------+------------+-----------------------------------+
| Query_ID | Duration | Query |
+----------+------------+-----------------------------------+
| 1 | 0.00214400 | show variables like '%profiling%' |
| 2 | 0.00017400 | select @@profiling |
| 3 | 3.00062925 | select sleep(3) |
| 4 | 0.00023450 | select * from test01 |
+----------+------------+-----------------------------------+
4 rows in set, 1 warning (0.00 sec)
如上所示，它会记录所有的语句，其中第二列Duration代表的是执行时间。
以上虽然可以看到每条SQL的执行时间，但我们无法精确知道有多少时间花费在IO上，多少时间花费在CPU上，因此，还可使用以下语句查看更为精确的内容：
show profile all for query $(Query_ID);
上面的Query_ID即show profiles结果中第一列的id编号。如：
mysql> show profile all for query 4;
+----------------------+----------+----------+------------+-------------------+---------------------+--------------+---------------+---------------+-------------------+-------------------+-------------------+-------+-----------------------+----------------------+-------------+
| Status | Duration | CPU_user | CPU_system | Context_voluntary | Context_involuntary | Block_ops_in | Block_ops_out | Messages_sent | Messages_received | Page_faults_major | Page_faults_minor | Swaps | Source_function | Source_file
| Source_line |
+----------------------+----------+----------+------------+-------------------+---------------------+--------------+---------------+---------------+-------------------+-------------------+-------------------+-------+-----------------------+----------------------+-------------+
| starting | 0.000045 | 0.000000 | 0.000000 | 0 | 0 | 0 |
0 | 0 | 0 | 0 | 0 | 0 | NULL | NULL
| NULL |
| checking permissions | 0.000008 | 0.000000 | 0.000000 | 0 | 0 | 0 |
0 | 0 | 0 | 0 | 0 | 0 | check_access | sql_authorization.cc | 809 |
| Opening tables | 0.000020 | 0.000000 | 0.000000 | 0 | 0 | 0 |
0 | 0 | 0 | 0 | 0 | 0 | open_tables | sql_base.cc
| 5781 |
| init | 0.000017 | 0.000000 | 0.000000 | 0 | 0 | 0 |
0 | 0 | 0 | 0 | 0 | 0 | handle_query | sql_select.cc
| 128 |
| System lock | 0.000016 | 0.000000 | 0.000000 | 0 | 0 | 0 |
0 | 0 | 0 | 0 | 2 | 0 | mysql_lock_tables | lock.cc
| 330 |
| optimizing | 0.000005 | 0.000000 | 0.000000 | 0 | 0 | 0 |
0 | 0 | 0 | 0 | 0 | 0 | optimize | sql_optimizer.cc
| 158 |
| statistics | 0.000014 | 0.000000 | 0.000000 | 0 | 0 | 0 |
0 | 0 | 0 | 0 | 0 | 0 | optimize | sql_optimizer.cc
| 374 |
| preparing | 0.000010 | 0.000000 | 0.000000 | 0 | 0 | 0 |
0 | 0 | 0 | 0 | 0 | 0 | optimize | sql_optimizer.cc
| 482 |
| executing | 0.000004 | 0.000000 | 0.000000 | 0 | 0 | 0 |
0 | 0 | 0 | 0 | 0 | 0 | exec | sql_executor.cc
| 126 |
| Sending data | 0.000051 | 0.000000 | 0.000000 | 0 | 0 | 0 |
0 | 0 | 0 | 0 | 8 | 0 | exec | sql_executor.cc
| 202 |
| end | 0.000005 | 0.000000 | 0.000000 | 0 | 0 | 0 |
0 | 0 | 0 | 0 | 0 | 0 | handle_query | sql_select.cc
| 206 |
| query end | 0.000007 | 0.000000 | 0.000000 | 0 | 0 | 0 |
0 | 0 | 0 | 0 | 0 | 0 | mysql_execute_command | sql_parse.cc
| 4956 |
| closing tables | 0.000007 | 0.000000 | 0.000000 | 0 | 0 | 0 |
0 | 0 | 0 | 0 | 0 | 0 | mysql_execute_command | sql_parse.cc
| 5009 |
| freeing items | 0.000013 | 0.000000 | 0.000000 | 0 | 0 | 0 |
0 | 0 | 0 | 0 | 0 | 0 | mysql_parse | sql_parse.cc
| 5622 |
| cleaning up | 0.000013 | 0.000000 | 0.000000 | 0 | 0 | 0 |
0 | 0 | 0 | 0 | 0 | 0 | dispatch_command | sql_parse.cc
| 1931 |
+----------------------+----------+----------+------------+-------------------+---------------------+--------------+-------------
--+---------------+-------------------+-------------------+-------------------+-------+-----------------------+------------------
----+-------------+
15 rows in set, 1 warning (0.00 sec)
上面的结果由于选项太多，看起来还是有些乱，其实很多东西我们并不关注，而主要只关注CPU和IO情况，因此，可以进一步简化如下：
mysql> show profile cpu, block io for query 4;
+----------------------+----------+----------+------------+--------------+---------------+
| Status | Duration | CPU_user | CPU_system | Block_ops_in | Block_ops_out |
+----------------------+----------+----------+------------+--------------+---------------+
| starting | 0.000045 | 0.000000 | 0.000000 | 0 | 0 |
| checking permissions | 0.000008 | 0.000000 | 0.000000 | 0 | 0 |
| Opening tables | 0.000020 | 0.000000 | 0.000000 | 0 | 0 |
| init | 0.000017 | 0.000000 | 0.000000 | 0 | 0 |
| System lock | 0.000016 | 0.000000 | 0.000000 | 0 | 0 |
| optimizing | 0.000005 | 0.000000 | 0.000000 | 0 | 0 |
| statistics | 0.000014 | 0.000000 | 0.000000 | 0 | 0 |
| preparing | 0.000010 | 0.000000 | 0.000000 | 0 | 0 |
| executing | 0.000004 | 0.000000 | 0.000000 | 0 | 0 |
| Sending data | 0.000051 | 0.000000 | 0.000000 | 0 | 0 |
| end | 0.000005 | 0.000000 | 0.000000 | 0 | 0 |
| query end | 0.000007 | 0.000000 | 0.000000 | 0 | 0 |
| closing tables | 0.000007 | 0.000000 | 0.000000 | 0 | 0 |
| freeing items | 0.000013 | 0.000000 | 0.000000 | 0 | 0 |
| cleaning up | 0.000013 | 0.000000 | 0.000000 | 0 | 0 |
+----------------------+----------+----------+------------+--------------+---------------+
15 rows in set, 1 warning (0.00 sec)
全局查询日志
同profiles一样，打开全局查询日志选项以后，它会记录下所有SQL语句，但是由于该操作比较耗费性能，因此，只建议在开发环境临时打开该选项。
查看全局查询日志命令：
mysql> show variables like '%general_log%';
+------------------+------------------------------------+
| Variable_name | Value |
+------------------+------------------------------------+
| general_log | OFF |
| general_log_file | /var/lib/mysql/DESKTOP-Q5J25HR.log |
+------------------+------------------------------------+
2 rows in set (0.01 sec)
打开全局查询日志选项：
set global general_log = on;
再次查询：
mysql> show variables like '%general_log%';
+------------------+------------------------------------+
| Variable_name | Value |
+------------------+------------------------------------+
| general_log | ON |
| general_log_file | /var/lib/mysql/DESKTOP-Q5J25HR.log |
+------------------+------------------------------------+
2 rows in set (0.00 sec)
设置完以上之后，还需要做如下设置：
set global log_output = 'table';
同样的，准备以下SQL：
select * from test01;
select id, name from test01 where id = 1;
全局查询日志记录在mysql.general_log表中。
mysql> select * from mysql.general_log;
+----------------------------+---------------------------+-----------+-----------+--------------+------------------------------------------+
| event_time | user_host | thread_id | server_id | command_type | argument
|
+----------------------------+---------------------------+-----------+-----------+--------------+------------------------------------------+
| 2020-03-31 22:31:24.750895 | root[root] @ localhost [] | 6 | 0 | Query | select * from test01
|
| 2020-03-31 22:31:26.128924 | root[root] @ localhost [] | 6 | 0 | Query | select id, name from test01 whe
re id = 1 |
| 2020-03-31 22:32:15.736558 | root[root] @ localhost [] | 6 | 0 | Query | select * from mysql.general_log
|
+----------------------------+---------------------------+-----------+-----------+--------------+--------------------------------
----------+
3 rows in set (0.01 sec)
既然有记录到表中，自然也有记录到文件中，只需要做如下设置：
set global general_log_file = '/tmp/mysql_general.log'; --设置文件路径
set global log_output = 'file'; --设置记录到文件
可通过如下命令查看文件路径：
mysql> show variables like '%general_log%';
+------------------+------------------------+
| Variable_name | Value |
+------------------+------------------------+
| general_log | ON |
| general_log_file | /tmp/mysql_general.log |
+------------------+------------------------+
2 rows in set (0.00 sec)
同样执行以上两条SQL：
select * from test01;
select id, name from test01 where id = 1;
查看文件内容，得到如下结果：
chenyc@DESKTOP-Q5J25HR:~$ sudo cat /tmp/mysql_general.log
/usr/sbin/mysqld, Version: 5.7.29-0ubuntu0.18.04.1 ((Ubuntu)). started with:
Tcp port: 3306 Unix socket: /var/run/mysqld/mysqld.sock
Time Id Command Argument
2020-03-31T14:35:49.793176Z 6 Query show variables like '%general_log%'
2020-03-31T14:37:20.241374Z 6 Query select * from test01
2020-03-31T14:37:21.408617Z 6 Query select id, name from test01 where id = 1
MySQL优化之慢查询日志的更多相关文章
- Mysql优化_慢查询开启说明及Mysql慢查询分析工具mysqldumpslow用法讲解
Mysql优化_慢查询开启说明及Mysql慢查询分析工具mysqldumpslow用法讲解 Mysql慢查询开启 Mysql的查询讯日志是Mysql提供的一种日志记录,它用来记录在Mysql中响应 ...
- mysql 优化2 慢查询
默认情况下mysql不记录慢查询日志,需要在启动的时候指定 bin\mysqld.exe - -slow-query-log 通过慢查询日志定位执行效率较低的SQL语句.慢查询日志记录了所有执行时间超 ...
- SQL语句技巧_索引的优化_慢查询日志开启_root密码的破解
1.正则表达式的使用 regexp例:select name,email from t where email regexp '@163[.,]com$'使用like方式查询selct name,em ...
- mysql优化：慢查询分析、索引配置优化
一.优化概述二.查询与索引优化分析a.性能瓶颈定位show命令慢查询日志explain分析查询profiling分析查询b.索引及查询优化三.配置优化 max_connections back_log ...
- Mysql 优化，慢查询
最近项目上遇到点问题,服务器出现连接超时.上次也是超时,问题定位到mongodb上,那次我修改好了,这次发现应该不是这个的问题了. 初步怀疑是mysql这边出问题了,写的sql没经过压力测试,导致用户 ...
- mysql中的慢查询日志
首先我们看一下关于mysql中的日志,主要包含:错误日志.查询日志.慢查询日志.事务日志.二进制日志: 日志是mysql数据库的重要组成部分.日志文件中记录着mysql数据库运行期间发生的变化:也就是 ...
- Mysql优化系列之查询性能优化前篇1
前言 这是优化系列的最后一篇的第1小篇,我们其实可以直接从sql怎么写讲起,why not?但是我还是决定花2个篇幅 问一些问题,带着几个问题循序渐进的往下走. 一个sql语句是怎么被执行的? sql ...
- MySQL 5.7 启用查询日志
MySQL版本:5.7 新版本的 my.ini 文件改动了,导致原先启用查询日志的方法不再适用 新版本的启用方法如下: 1. 修改 C:\ProgramData\MySQL\MySQL Server ...
- Mysql优化之Explain查询计划查看
我们经常说到mysql优化,优化中一种常见的方式就是对于经常查询的字段创建索引.那么mysql中有哪些索引类型呢? 一.索引分类1.普通索引:即一个索引只包含单个列,一个表可以有多个单列索引 2.唯一 ...
随机推荐
- 基于USB接口芯片CH372的人机接口设备设计与实现（转）
摘 要: 基于一种新型USB 总线接口芯片CH372,设计出一种人机接口设备-USB 鼠标.阐述了CH372 的工作原理和特点,给出了系统的硬件电路图:在软件设计中,分析了HID 类设备描述符枚举过程 ...
- 安卓注解处理器-processor
最近在学习安卓开源框架发现,很多的开源框架都使用到了注解处理器,例如EventBus3.0.本文通过一个简单的Demo来介绍如何使用注解处理器.Demo链接为https://github.com/cu ...
- GLPI 0.85.5 上传漏洞分析
在exp-db上面看到的漏洞,这是原文链接:https://www.exploit-db.com/exploits/38407/ 但是POC给的很简单,这是原来的描述: " The appl ...
- Scheme实现数字电路仿真(3)——模块
版权申明:本文为博主窗户(Colin Cai)原创,欢迎转帖.如要转贴,必须注明原文网址 http://www.cnblogs.com/Colin-Cai/p/12242650.html 作者:窗户 ...
- hadoop地址配置、内存配置、守护进程设置、环境设置
1.1 hadoop配置 hadoop配置文件在安装包的etc/hadoop目录下,但是为了方便升级,配置不被覆盖一般放在其他地方,并用环境变量HADOOP_CONF_DIR指定目录. 1.1.1 ...
- USB小白学习之路（12） Cy7c68013A固件之Slave FIFO(转)
Cy7c68013固件之Slave FIFO 转自:http://blog.csdn.net/zengshaoqing/article/details/53053539 选择SlaveFIFO传输方式 ...
- 【Mood】在COVID-19疫情中
看完网课(这还得从一只蝙蝠说起...),本来准备刷几道题. 还是来记录下这次事件吧. 2月1号,病毒感染人数破万. 接下来4天(今日6号)疫情走向爆发期. 每日平均新增发病人数达到了3000~4000 ...
- sql -- 获取连续签到的用户列表
签到表: 需求:统计连续签到的 用户 1.根据用户和日期分组 select user_name, sign_date from user_sign group by user_name, sign_d ...
- js事件的三个阶段
js事件的三个阶段分别为:捕获.目标.冒泡 1.捕获:事件由页面元素接收,逐级向下,到具体的元素 2.目标:具体的元素本身 3.冒泡:跟捕获相反,具体元素本身,逐级向上,到页面元素 IE5.5:div ...
- 关于使用Binlog和canal来对MySQL的数据写入进行监控
先说下Binlog和canal是什么吧. 1.Binlog是mysql数据库的操作日志,当有发生增删改查操作时,就会在data目录下生成一个log文件,形如mysql-bin.000001,mysql ...