文档章节

MySQL锁阻塞分析

梦想没有终点
 梦想没有终点
发布于 2016/02/03 11:03
字数 2330
阅读 15
收藏 0

日常维护中,经常会碰到线程被阻塞,导致数据库响应非常慢,下面就看看如何获取是哪个线程导致了阻塞的。

blog地址:http://blog.csdn.net/hw_libo/article/details/39080809

1. 环境说明

RHEL 6.4 x86_64 + MySQL 5.6.19
事务隔离级别:RR

2. 测试过程

\

3. 查看锁阻塞线程信息

这里用几中方法进行分析:

3.1 使用show processlist查看

?

1
2
3
4
5
6
7
8
9
10
MySQL [(none)]> show processlist;
+ ----+------+-----------+------+---------+------+--------------+------------------------------------------+
| Id | User | Host      | db   | Command | Time | State        | Info                                     |
+ ----+------+-----------+------+---------+------+--------------+------------------------------------------+
|  2 | root | localhost | NULL | Query   |    0 | init         | show processlist                         |
|  3 | root | localhost | test | Query   |   70 | Sending data | select count (*) from t3 a,t3 b           |
|  4 | root | localhost | test | Query   |   65 | updating     | delete from emp where empno=7788         |
|  7 | root | localhost | test | Query   |   68 | updating     | update emp set sal=3500 where empno=7788 |
+ ----+------+-----------+------+---------+------+--------------+------------------------------------------+
4 rows in set (0.00 sec)

如果数据库存在较多线程的话,这种方法确实不太好确认的。

3.2 直接使用show engine innodb status查看

?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
------------
TRANSACTIONS
------------
Trx id counter 4131
Purge done for trx's n:o < 4119 undo n:o < 0 state: running but idle
History list length 126
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 0, not started
MySQL thread id 2, OS thread handle 0x7f953ffff700, query id 115 localhost root init
show engine innodb status
---TRANSACTION 4130, ACTIVE 41 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 4, OS thread handle 0x7f953ff9d700, query id 112 localhost root updating
delete from emp where empno=7788
------- TRX HAS BEEN WAITING 41 SEC FOR THIS LOCK TO BE GRANTED:   ## 等待了41s
RECORD LOCKS space id 16 page no 3 n bits 88 index ` PRIMARY ` of table `test`.`emp` trx id 4130 lock_mode X locks rec but not gap waiting
Record lock, heap no 9 PHYSICAL RECORD: n_fields 10; compact format; info bits 0  ## 线程4在等待往test.emp中的主键上加X锁,page num=3
  0: len 4; hex 80001e6c; asc    l;;
  1: len 6; hex 000000001018; asc       ;;
  2: len 7; hex 91000001420084; asc     B  ;;
  3: len 5; hex 53434f5454; asc SCOTT;;
  4: len 7; hex 414e414c595354; asc ANALYST;;
  5: len 4; hex 80001d8e; asc     ;;
  6: len 4; hex 208794f0; asc     ;;
  7: len 4; hex 80000bb8; asc     ;;
  8: SQL NULL ;
  9: len 4; hex 80000014; asc     ;;
 
------------------
---TRANSACTION 4129, ACTIVE 45 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 7, OS thread handle 0x7f953ff6c700, query id 111 localhost root updating
update emp set sal=3500 where empno=7788
------- TRX HAS BEEN WAITING 45 SEC FOR THIS LOCK TO BE GRANTED:   ## 等待了45s
RECORD LOCKS space id 16 page no 3 n bits 88 index ` PRIMARY ` of table `test`.`emp` trx id 4129 lock_mode X locks rec but not gap waiting
Record lock, heap no 9 PHYSICAL RECORD: n_fields 10; compact format; info bits 0  ## 线程7在等待往test.emp中的主键上加X锁,page num=3
  0: len 4; hex 80001e6c; asc    l;;
  1: len 6; hex 000000001018; asc       ;;
  2: len 7; hex 91000001420084; asc     B  ;;
  3: len 5; hex 53434f5454; asc SCOTT;;
  4: len 7; hex 414e414c595354; asc ANALYST;;
  5: len 4; hex 80001d8e; asc     ;;
  6: len 4; hex 208794f0; asc     ;;
  7: len 4; hex 80000bb8; asc     ;;
  8: SQL NULL ;
  9: len 4; hex 80000014; asc     ;;
 
------------------
---TRANSACTION 4128, ACTIVE 51 sec
2 lock struct(s), heap size 360, 1 row lock(s)
MySQL thread id 3, OS thread handle 0x7f953ffce700, query id 110 localhost root cleaning up

我们知道,主要根因还是thread=3引起的,但从innodb status中却无法分析得到这个结果。

从上面来看,线程4和线程7都在等待往test.emp中的主键上加X锁,page num=3,但是线程7等待的时间为45s,而线程4等待的时间为41s,是较线程7之后申请的锁,所以可以判断是线程7阻塞了线程4。至于线程7为什么出现等待,这里分析不到根因。

3.3 使用mysqladmin debug查看

# mysqladmin -S /tmp/mysql3306.sock debug

然后在error日志中,会看到:

?

1
2
3
4
5
Thread database .table_name          Locked/Waiting        Lock_type
 
 
3       test.t3                     Locked - read         Low priority read lock
7       test.emp                    Locked - write        High priority write lock

这种方法中,能找到线程ID=3和7是阻塞者,但还是不太准确,判断不出来线程7也是被线程ID=3阻塞的。

3.4 使用innodb_lock_monitor来获取阻塞锁线程

?

1
2
3
4
5
6
7
8
9
MySQL [test]> CREATE TABLE innodb_lock_monitor (a INT ) ENGINE=INNODB;  ## 随便在一个数据库中创建这个表,就会打开lock monitor
Query OK, 0 rows affected, 1 warning (0.07 sec)
 
MySQL [test]> show warnings\G
*************************** 1. row ***************************
   Level : Warning
    Code: 131
Message: Using the table name innodb_lock_monitor to enable diagnostic output is deprecated and may be removed in future releases. Use INFORMATION_SCHEMA or PERFORMANCE_SCHEMA tables or SET GLOBAL innodb_status_output= ON .
1 row in set (0.00 sec)

说明:这个在5.6中有一个warning,但不影响使用。

然后再使用show engine innodb status查看: 

?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
------------
TRANSACTIONS
------------
Trx id counter 4667
Purge done for trx's n:o < 4659 undo n:o < 0 state: running but idle
History list length 138
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 0, not started
MySQL thread id 9, OS thread handle 0x7f813c5f7700, query id 152 localhost root init
show engine innodb status
---TRANSACTION 4663, ACTIVE 78 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 4, OS thread handle 0x7f813c628700, query id 149 localhost root updating
delete from emp where empno=7788
------- TRX HAS BEEN WAITING 78 SEC FOR THIS LOCK TO BE GRANTED:   ## 等待了78s
RECORD LOCKS space id 16 page no 3 n bits 88 index ` PRIMARY ` of table `test`.`emp` trx id 4663 lock_mode X locks rec but not gap waiting
Record lock, heap no 9 PHYSICAL RECORD: n_fields 10; compact format; info bits 0  ## 线程4在等待往test.emp中的主键上加X锁,page num=3
  0: len 4; hex 80001e6c; asc    l;;
  1: len 6; hex 000000001018; asc       ;;
  2: len 7; hex 91000001420084; asc     B  ;;
  3: len 5; hex 53434f5454; asc SCOTT;;
  4: len 7; hex 414e414c595354; asc ANALYST;;
  5: len 4; hex 80001d8e; asc     ;;
  6: len 4; hex 208794f0; asc     ;;
  7: len 4; hex 80000bb8; asc     ;;
  8: SQL NULL ;
  9: len 4; hex 80000014; asc     ;;
 
------------------
TABLE LOCK table `test`.`emp` trx id 4663 lock mode IX   ## 在给主键行上加X锁之前,先要在表上加意向锁IX
RECORD LOCKS space id 16 page no 3 n bits 88 index ` PRIMARY ` of table `test`.`emp` trx id 4663 lock_mode X locks rec but not gap waiting
Record lock, heap no 9 PHYSICAL RECORD: n_fields 10; compact format; info bits 0
  0: len 4; hex 80001e6c; asc    l;;
  1: len 6; hex 000000001018; asc       ;;
  2: len 7; hex 91000001420084; asc     B  ;;
  3: len 5; hex 53434f5454; asc SCOTT;;
  4: len 7; hex 414e414c595354; asc ANALYST;;
  5: len 4; hex 80001d8e; asc     ;;
  6: len 4; hex 208794f0; asc     ;;
  7: len 4; hex 80000bb8; asc     ;;
  8: SQL NULL ;
  9: len 4; hex 80000014; asc     ;;
 
---TRANSACTION 4662, ACTIVE 81 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 7, OS thread handle 0x7f813c5c6700, query id 148 localhost root updating
update emp set sal=3500 where empno=7788
------- TRX HAS BEEN WAITING 81 SEC FOR THIS LOCK TO BE GRANTED:  ## 等待了81s
RECORD LOCKS space id 16 page no 3 n bits 88 index ` PRIMARY ` of table `test`.`emp` trx id 4662 lock_mode X locks rec but not gap waiting
Record lock, heap no 9 PHYSICAL RECORD: n_fields 10; compact format; info bits 0  ## 线程7在等待往test.emp中的主键上加X锁,page num=3
  0: len 4; hex 80001e6c; asc    l;;
  1: len 6; hex 000000001018; asc       ;;
  2: len 7; hex 91000001420084; asc     B  ;;
  3: len 5; hex 53434f5454; asc SCOTT;;
  4: len 7; hex 414e414c595354; asc ANALYST;;
  5: len 4; hex 80001d8e; asc     ;;
  6: len 4; hex 208794f0; asc     ;;
  7: len 4; hex 80000bb8; asc     ;;
  8: SQL NULL ;
  9: len 4; hex 80000014; asc     ;;
 
------------------
TABLE LOCK table `test`.`emp` trx id 4662 lock mode IX   ## 在给主键行上加X锁之前,先要在表上加意向锁IX
RECORD LOCKS space id 16 page no 3 n bits 88 index ` PRIMARY ` of table `test`.`emp` trx id 4662 lock_mode X locks rec but not gap waiting
Record lock, heap no 9 PHYSICAL RECORD: n_fields 10; compact format; info bits 0
  0: len 4; hex 80001e6c; asc    l;;
  1: len 6; hex 000000001018; asc       ;;
  2: len 7; hex 91000001420084; asc     B  ;;
  3: len 5; hex 53434f5454; asc SCOTT;;
  4: len 7; hex 414e414c595354; asc ANALYST;;
  5: len 4; hex 80001d8e; asc     ;;
  6: len 4; hex 208794f0; asc     ;;
  7: len 4; hex 80000bb8; asc     ;;
  8: SQL NULL ;
  9: len 4; hex 80000014; asc     ;;
 
---TRANSACTION 4615, ACTIVE 1579 sec, thread declared inside InnoDB 1222
mysql tables in use 2, locked 0
2 lock struct(s), heap size 360, 1 row lock(s)
MySQL thread id 3, OS thread handle 0x7f813c659700, query id 147 localhost root Sending data
select count (*) from t3 a,t3 b   ## 这是线程3当前正在执行的SQL
Trx read view will not see trx with id >= 4662, sees < 4659
TABLE LOCK table `test`.`emp` trx id 4615 lock mode IX  ## 线程3中正在拥有表上的意向IX锁,并且有test.emp表上主键的行级X锁,page num=3
RECORD LOCKS space id 16 page no 3 n bits 88 index ` PRIMARY ` of table `test`.`emp` trx id 4615 lock_mode X locks rec but not gap
Record lock, heap no 9 PHYSICAL RECORD: n_fields 10; compact format; info bits 0
  0: len 4; hex 80001e6c; asc    l;;
  1: len 6; hex 000000001018; asc       ;;
  2: len 7; hex 91000001420084; asc     B  ;;
  3: len 5; hex 53434f5454; asc SCOTT;;
  4: len 7; hex 414e414c595354; asc ANALYST;;
  5: len 4; hex 80001d8e; asc     ;;
  6: len 4; hex 208794f0; asc     ;;
  7: len 4; hex 80000bb8; asc     ;;
  8: SQL NULL ;
  9: len 4; hex 80000014; asc     ;;

为什么线程3当前执行的是一个select t3表操作,但却锁住了test.emp表上page num=3?
有可能是线程3之前对test.emp表的操作事务没有及时提交导致。
所以得出:线程3阻塞了线程7,而线程7又阻塞了线程4,所以根因就是线程3,让线程3尽快提交或是kill掉即可。

4. 结论

在分析innodb中锁阻塞时,几种方法的对比情况:

(1)使用show processlist查看不靠谱;
(2)直接使用show engine innodb status查看,无法判断到问题的根因;
(3)使用mysqladmin debug查看,能看到所有产生锁的线程,但无法判断哪个才是根因;
(4)开启innodb_lock_monitor后,再使用show engine innodb status查看,能够找到锁阻塞的根因。

blog地址:http://blog.csdn.net/hw_libo/article/details/39080809

-- Bosco QQ:375612082
---- END ----


本文转载自:http://www.2cto.com/database/201409/331777.html

梦想没有终点
粉丝 2
博文 31
码字总数 28266
作品 0
海淀
私信 提问
MySQL 不同隔离级别加锁情况

对于MySQL 各种隔离级别的加锁情况分析的博客很多 但对 read uncommitted 这个级别的加锁情况分析总是一笔带过。 甚至美团的博客简述 read uncommitted 隔离级别不加任何锁。 但我分析下来确...

mark_rock
2017/03/26
173
1
处理MySQL数据库出现大量Locked的一个案例

MySQL在使用过程中遇到访问速度慢,或者无法响应这类的问题,解决方式基本都有定式,一般第一反应都会是登录到MySQL, show processlist看看当前连接状态。 虽说简单,但show processlist显示...

庆沉
2015/06/30
0
0
mysql并发insert死锁问题——gap、插入意向锁冲突

问题描述 线上出现MySQL死锁报警,通过show engine innodb status命令查看死锁日志,结合异常代码,还原发生死锁的事务场景如下: 环境: mysql5.7,事务隔离级别REPEATABLE-READ 表结构 并发...

hebaodan
2018/06/26
0
1
MySQLwwwhj8828com18088045700锁分析和监控

通常在MySQL的管理和监控中,Active Session(活动会话)是监控指标中的一个很重要的指标,通过活动会话监控,可以很清楚的了解到数据库当前是否有SQL堆积,是否处于非常繁忙的状态。那么除了...

1597538646291241
2018/10/04
0
0
mysql查询更新时的锁表机制分析

为了给高并发情况下的mysql进行更好的优化,有必要了解一下mysql查询更新时的锁表机制。 一、概述 MySQL有三种锁的级别:页级、表级、行级。 MyISAM和MEMORY存储引擎采用的是表级锁(table-l...

桔子
2013/06/28
0
3

没有更多内容

加载失败,请刷新页面

加载更多

windows下cmd常用的命令

windows下常用的命令指示行: windows下 CMD比较常见的命令1. gpedit.msc-----组策略 2. sndrec32-------录音机 3. Nslookup-------IP地址侦测器 4. explorer-------打开资源管理器...

WinkJie
12分钟前
1
0
折叠手机适配布局

CSS Grid 设备相关参数 媒体查询 Chrome进行调试,创建相应的模拟机

lilugirl
13分钟前
0
0
Knative Eventing 中如何实现 Registry 事件注册机制

摘要: 在最新的 Knative Eventing 0.6 版本中新增了 Registry 特性, 为什么要增加这个特性, 该特性是如何实现的。针对这些问题,希望通过本篇文章给出答案。 背景 作为事件消费者,之前是...

阿里云云栖社区
17分钟前
0
0
安装 jemalloc for mysql

前言: Jemalloc 是BSD的提供的内存分配管理 安装依赖 $ yum install -y gcc$ yum install autoconf -y 安装 jemalloc $ git clone https://github.com/jemalloc/jemalloc$ cd jema......

Linux_Anna
27分钟前
0
0
linux下ctrl+c中止不了

有一台centos7的服务器,ctrl+c无效,并且tail -f也无效,只能关掉终端或者crtl+z放入后台再删掉,但是ping的时候使用ctrl+c是有效果的。 出现这种情况的原因可能是因为有人要使用ruby安装r...

gaolongquan
41分钟前
1
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部