为什么不记录慢查询？

最新推荐文章于 2025-04-21 15:01:12 发布

原创最新推荐文章于 2025-04-21 15:01:12 发布 · 6.9k 阅读

0 ·

CC 4.0 BY-SA版权

MySQL 优化与深入专栏收录该内容

25 篇文章

订阅专栏

本文记录了一次因长时间运行的SQL事务导致前端玩家出现掉线的问题排查过程。通过查看InnoDB事务状态，发现一执行超过1小时的SQL未正常结束，Kill进程后问题解决。分析得出，仅当Query_time-Lock_time超过long_query_time阈值时，SQL才会被记录到慢查询日志。

㈠背景介绍：

2014/8/18 13点37分收到前端说反馈有玩家掉线情况，检查CPU、慢查询、DB请求量，并未发现异常，DB表现一如往常。

㈡定位原因：

INSERT INTO t (col1, col2, col3, col4, col5, col6, col7) VALUES ('3532082239485507011_130_99', '130_99', 130, 99, 3532082239485507011, 2172353000317425008, 29078)

这个长事务执行 1个多小时没有退出，Kill 掉对应的进程，程序前端恢复正常

㈢处理思路：

⑴ 查询视图

select trx_id,trx_state,trx_started,trx_requested_lock_id,trx_weight,trx_mysql_thread_id from information_schema.innodb_trx where trx_state='RUNNING';

⑵ show engine innodb status\G; 关注Transactions部分提取SQL及事务信息

㈣我的疑问：

为什么这条执行了1个多小时的SQL没有被记录到慢查询日志中呢？？

㈤原来如此：

Query_time - Lock_time > long_query_time <===记录
Query_time - Lock_time < long_query_time <===不记录

㈥模拟场景：

⑴ Query_time - Lock_time > long_query_time

Session_A：

mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> select emp_no,hire_date from employees where emp_no=10170 for update;
+--------+------------+
| emp_no | hire_date  |
+--------+------------+
|  10170 | 1986-01-02 |
+--------+------------+
1 row in set (0.00 sec)

Session_B:

mysql> select emp_no,hire_date,sleep(3) from employees where emp_no=10170 for update;

过段时间在A做commit，B会执行、并被记录到slow log中：

# Time: 140818 22:37:31
# User@Host: root[root] @ localhost []  Id:     1
# Query_time: 3.049016  Lock_time: 0.018891 Rows_sent: 1  Rows_examined: 1
use employees;
SET timestamp=1408372651;
select emp_no,hire_date,sleep(3) from employees where emp_no=10170 for update;

⑵ Query_time - Lock_time < long_query_time

Session_A：

mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> select emp_no,hire_date from employees where emp_no=10170 for update;
+--------+------------+
| emp_no | hire_date  |
+--------+------------+
|  10170 | 1986-01-02 |
+--------+------------+
1 row in set (0.00 sec)

Session_B:

mysql> select emp_no,hire_date from employees where emp_no=10170 for update;

过段时间在A做commit，B会执行、但不会被记录到slow log中

㈦我的收获：

我们日常做性能剖析实际上应该包括2个方面：

1）基于执行时间的分析

2）基于等待时间的分析

By water

Good Luck！