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;
3. 结论
1)Query_time – Lock_time > long_query_time <==> 记录
1)Query_time – Lock_time < long_query_time <==> 不记录