mysql怎么找曾经阻塞的sql_MySQL Innodb如何找出阻塞事务源头SQL

在MySQL数据库中出现了阻塞问题，如何快速查找定位问题根源？在实验开始前，我们先梳理一下有什么工具或命令查看MySQL的阻塞，另外，我们也要一一对比其优劣，因为有些命令可能在实际环境下可能并不适用。

1：show engine innodb status

2：Innotop工具

3：INNODB_TRX 等系统表

下面我们理论联系实际，通过实验来测试总结一下这个问题。首先构造测试环境，数据库测试环境为( 5.7.21 MySQL Community Server 和5.6.20-enterprise-commercial，这两个测试环境我都测试验证过)

mysql> use MyDB;Reading table information for completion of table and column namesYou can turn off this feature to get a quicker startup with -ADatabase changedmysql> create table test_blocking(id int primary key, name varchar(12));Query OK, 0 rows affected (0.05 sec)mysql> insert into test_blocking-> select 1, 'kerry' from dual;Query OK, 1 row affected (0.00 sec)Records: 1  Duplicates: 0  Warnings: 0mysql> insert into test_blocking-> select 2, 'jimmy' from dual;Query OK, 1 row affected (0.00 sec)Records: 1  Duplicates: 0  Warnings: 0mysql> insert into test_blocking-> select 3, 'kkk' from dual;Query OK, 1 row affected (0.00 sec)Records: 1  Duplicates: 0  Warnings: 0

准备好测试环境数据后，那么我们接下来开始实验，为了实验效果，我们先将参数innodb_lock_wait_timeout设置为100。

mysql> show variables like 'innodb_lock_wait_timeout';+--------------------------+-------+| Variable_name            | Value |+--------------------------+-------+| innodb_lock_wait_timeout | 50    |+--------------------------+-------+1 row in set (0.00 sec)mysql> set global innodb_lock_wait_timeout=100 ;Query OK, 0 rows affected (0.00 sec)mysql> select connection_id() from dual;+-----------------+| connection_id() |+-----------------+|               8 |+-----------------+1 row in set (0.00 sec)mysql> set session autocommit=0;Query OK, 0 rows affected (0.00 sec)mysql> select * from test_blocking where id=1 for update;+----+-------+| id | name  |+----+-------+|  1 | kerry |+----+-------+1 row in set (0.00 sec)

然后在第二个连接会话中执行更新脚本，构造被阻塞的案例

mysql> select connection_id() from dual;+-----------------+| connection_id() |+-----------------+|               9 |+-----------------+1 row in set (0.00 sec)mysql> update test_blocking set name='kk' where id=1;

在第三个连接会话执行下面命令，查看TRANSACTIONS相关信息：

mysql> show engine innodb status\G;

使用show engine innodb status命令后，可以查看其输出的TRANSACTIONS部分信息，如上截图所示，找到类似TRX HAS BEEN WATING ...部分的信息，

通过那部分信息，我们可以看到update test_blocking set name='kk' where id=1这个SQL语句被阻塞了14秒，一直在等待获取X Lock。

TRANSACTIONS

------------

Trx id counter 148281#下一个事务ID

Purge done for trx's n:o < 148273 undo n:o < 0 state: running but idle

History list length 552

LIST OF TRANSACTIONS FOR EACH SESSION:

---TRANSACTION 0, not started

MySQL thread id 15, OS thread handle 0x4cc64940, query id 261 localhost root cleaning up

---TRANSACTION 0, not started

MySQL thread id 14, OS thread handle 0x4cbe2940, query id 278 localhost root init

show engine innodb status

---TRANSACTION 148280, ACTIVE 24 sec

2 lock struct(s), heap size 360, 1 row lock(s)

MySQL thread id 8, OS thread handle 0x4cba1940, query id 276 localhost root cleaning up

---TRANSACTION 148279, ACTIVE 313 sec starting index read

mysql tables in use 1, locked 1

LOCK WAIT 2 lock struct(s), heap size 360, 1 row lock(s)

MySQL thread id 9, OS thread handle 0x4cc23940, query id 277 localhost root updating#线程ID为9， 操作系统线程句柄为0x4cc23940， 查询ID为277，账号为root的UPDATE操作

update test_blocking set name='kk' where id=1#具体SQL语句

------- TRX HAS BEEN WAITING 14 SEC FOR THIS LOCK TO BE GRANTED:#TRX等待授予锁已经有14秒了

RECORD LOCKS space id 337 page no 3 n bits 72 index `PRIMARY` of table `MyDB`.`test_blocking` trx id 148279 lock_mode X locks rec but not gap waiting

#在space id=337(test_blocking表的表空间)，page no=3的页上，表test_blocking上的主键索引在等待X锁

Record lock, heap no 2 PHYSICAL RECORD: n_fields 4; compact format; info bits 0

0: len 4; hex 80000001; asc;;#第一个字段是主键，制度按长为4，值为1

1: len 6; hex 000000024322; ascC";;#该字段为6个字节的事务id，这个id表示最近一次被更新的事务id(对应十进制为148258)

2: len 7; hex 9a000001f20110; asc;;#该字段为7个字节的回滚指针，用于mvcc

3: len 5; hex 6b65727279; asc kerry;;#该字段表示的是此记录的第二个字段，长度为5，值为kerry(如果表有多个字段，那么此处后面还有记录)

mysql> select * from information_schema.INNODB_SYS_DATAFILES where space=337;+-------+--------------------------+| SPACE | PATH                     |+-------+--------------------------+|   337 | ./MyDB/test_blocking.ibd |+-------+--------------------------+1 row in set (0.00 sec)mysql>

但是这种方式也有一些弊端，例如生产环境很复杂，尤其是有大量事务的情况下。诸多信息根本无法清晰判断知道谁阻塞了谁；其次一点也不直观； 另外，这个也无法定位blocker 的SQL语句。这种方式只能作为辅助分析用途，通过查看取锁的详细信息，帮助进一步诊断问题。

2: Innotop工具

如下所示，Innotop工具很多情况下也不能定位到阻塞的语句(Blocking Query)， 也仅仅能获取一些锁相关信息

3：通过查询information_schema数据库下与事务相关的几个系统表

还是构造之前的测试案例，在第一个会话中使用SELECT FOR UPDATE锁定其中一行记录

mysql> use MyDB;Database changedmysql>  set session autocommit=0;Query OK, 0 rows affected (0.00 sec)mysql> select connection_id() from dual;+-----------------+| connection_id() |+-----------------+|              17 |+-----------------+1 row in set (0.00 sec)mysql> select * from test_blocking where id=1 for update;+----+-------+| id | name  |+----+-------+|  1 | kerry |+----+-------+1 row in set (0.00 sec)mysql>

然后在第二个连接会话中执行更新脚本，构造被阻塞的案例

如您对本文有疑问或者有任何想说的，请点击进行留言回复，万千网友为您解惑！