MYSQL慢日志探索

最新推荐文章于 2025-06-30 20:11:00 发布

转载最新推荐文章于 2025-06-30 20:11:00 发布 · 605 阅读

MYSQL 专栏收录该内容

118 篇文章

订阅专栏

Table of Contents [hide]

1. 出现场景

今天审计SQL慢查询，发现一个很简单的SQL语句出现在了满日志里面，并且相应时间还很长，拿出去直接去查看执行计划，并没有发现什么问题。突然感觉为什么会记录在慢日志中感觉很模糊。亲自动手找一下原因吧
问题语句：select userid from tbl_name where mobile =?

2. 什么样的慢查询会记录到slow log日志

2.1 慢日志查询和锁定时间介绍

在Slog慢日志中，会有类似这样的数据，体现了2个参数，查询时间和所等待时间
# Query_time: 27.620161 Lock_time: 25.615839 Rows_sent: 1 Rows_examined: 1

2.2 何时记录慢日志

记录到慢日志的SQL与Query_time,Lock_time,long_query_time有什么关系呢？为了解决这个问题，我特意做了一个下面的实验,废话不在多说，准备测试数据

2.2.1 设置开启MySQL慢日志相关参数

我的设置如下:
slow_query_log=1
long_query_time=1
slow_query_log_file=/home/db/Main.Slow.log

2.2.2 准备测试数据

[localhost](dog) 11:17:45>CREATE TABLE Gbk_Null (
id int(11) NOT NULL AUTO_INCREMENT,
name char(10) DEFAULT NULL,
PRIMARY KEY (id),
KEY name(name)
) ENGINE=InnoDB AUTO_INCREMENT=7 DEFAULT CHARSET=gbk;
[localhost](dog) 12:17:02>select * from Gbk_Null;
+—-+——-+
| id | name |
+—-+——-+
| 1 | aaa |
| 2 | bbbb |
| 3 | cccc |
| 4 | ddd |
| 5 | eeee |
| 6 | fffff |
+—-+——-+
6 rows in set (0.00 sec)

2.2.3 测试场景介绍

场景1：
session A:
begin;
select * from Gbk_Null where id =1 for update;

Session B;
begin:
select *,sleep(2) from Gbk_Null where id =1 for update;

然后去场景中commit事务，观察是否有满日志记录到满日志文件中

场景2：
session A:
begin;
select * from Gbk_Null where id =1 for update;

Session B;
begin:
select * from Gbk_Null where id =1 for update;

然后去场景中commit事务，观察是否有满日志记录到满日志文件中

场景3：
session A:
begin;
select * from Gbk_Null where id =1 for update;

Session B;
begin:
select *,sleep(0.5) from Gbk_Null where id =1 for update;

2.2.3 测试结果展示

通过上面场景的测试，发现了场景1的Session B中SQL被记录到了满日志中，而场景2，场景3 没有任何的满日志记录信息，慢日志内容如下

# Time: 150227 11:12:52
# User@Host: root[root] @ localhost [127.0.0.1] Id: 9
# Query_time: 9.623483 Lock_time: 7.623200 Rows_sent: 1 Rows_examined: 1
use dog;
SET timestamp=1425006772;
select *,sleep(2) from Gbk_Null where id =1 for update;