MySQL - 锁等待超时与information_schema的三个表

引用地址：https://blog.csdn.net/J080624/article/details/80596958

回顾一下生产中的一次MySQL异常，Cause: java.sql.SQLException: Lock wait timeout exceeded; try restarting transaction解决与处理。

【1】抛个异常

异常如下：

Cause: java.sql.SQLException: Lock wait timeout exceeded;
try restarting transaction
1
2
翻译：锁等待超时，尝试重启事务。

【2】information_schema的三个表

information_schema.innodb_trx–当前运行的所有事务，
information_schema.innodb_locks–当前出现的锁
information_schema.innodb_lock_waits–锁等待的对应关系
① information_schema.innodb_trx–当前运行的所有事务

Field Type Null Key Default Extra
trx_id varchar(18) NO 事务ID
trx_state varchar(13) NO 事务状态：
trx_started datetime NO 0000-00-00 00:00:00 事务开始时间；
trx_requested_lock_id varchar(81) YES NULL innodb_locks.lock_id
trx_wait_started datetime YES NULL 事务开始等待的时间
trx_weight bigint(21) unsigned NO 0 事务权重
trx_mysql_thread_id bigint(21) unsigned NO 0 事务线程ID
trx_query varchar(1024) YES NULL 具体SQL语句
trx_operation_state varchar(64) YES NULL 事务当前操作状态
trx_tables_in_use bigint(21) unsigned NO 0 事务中有多少个表被使用
trx_tables_locked bigint(21) unsigned NO 0 事务拥有多少个锁
trx_lock_structs bigint(21) unsigned NO 0
trx_lock_memory_bytes bigint(21) unsigned NO 0 事务锁住的内存大小（B）
trx_rows_locked bigint(21) unsigned NO 0 事务锁住的行数
trx_rows_modified bigint(21) unsigned NO 0 事务更改的行数
trx_concurrency_tickets bigint(21) unsigned NO 0 事务并发票数
trx_isolation_level varchar(16) NO 事务隔离级别
trx_unique_checks int(1) NO 0 是否唯一性检查
trx_foreign_key_checks int(1) NO 0 是否外键检查
trx_last_foreign_key_error varchar(256) YES NULL 最后的外键错误
trx_adaptive_hash_latched int(1) NO 0
trx_adaptive_hash_timeout bigint(21) unsigned NO 0
② information_schema.innodb_locks–当前出现的锁

Field Type Null Key Default Extra
lock_id varchar(81) NO 锁ID
lock_trx_id varchar(18) NO 拥有锁的事务ID
lock_mode varchar(32) NO 锁模式
lock_type varchar(32) NO 锁类型
lock_table varchar(1024) NO 被锁的表
lock_index varchar(1024) YES NULL 被锁的索引
lock_space bigint(21) unsigned YES NULL 被锁的表空间号
lock_page bigint(21) unsigned YES NULL 被锁的页号
lock_rec bigint(21) unsigned YES NULL 被锁的记录号
lock_data varchar(8192) YES NULL 被锁的数据
③ information_schema.innodb_lock_waits–锁等待的对应关系

Field Type Null Key Default Extra
requesting_trx_id varchar(18) NO 请求锁的事务ID
requested_lock_id varchar(81) NO 请求锁的锁ID
blocking_trx_id varchar(18) NO 当前拥有锁的事务ID
blocking_lock_id varchar(81) NO 当前拥有锁的锁ID
开始测试

第一步：创建测试表tx1，并插入测试数据；

create table tx1
(id int primary key ,
c1 varchar(20),
c2 varchar(30)),
c3 datetime
engine=innodb default charset = utf8 ;

insert into tx1 values
(1,‘aaaa‘,‘aaaaa2‘,SYSDATE()),
(2,‘bbbb‘,‘bbbbb2‘,,SYSDATE()),
(3,‘cccc‘,‘ccccc2‘,,SYSDATE());
1
2
3
4
5
6
7
8
9
10
11
第二步：手动开启事务，查询三个表数据

start transaction;
update tx1 set c1=‘heyf‘,c2=‘heyf‘,c3=SYSDATE() where id =3 ;

select * from information_schema.innodb_trx;

select * from information_schema.INNODB_LOCKS;

select * from information_schema.INNODB_LOCK_WAITS;
1
2
3
4
5
6
7
8
此时没有锁，锁等待关系，只有innodb_trx表中有数据

*************************** 1. row ***************************
trx_id: 75E34
trx_state: RUNNING
trx_started: 2018-06-06 16:55:37
trx_requested_lock_id: NULL
trx_wait_started: NULL
trx_weight: 3
trx_mysql_thread_id: 235
trx_query: NULL
trx_operation_state: NULL
trx_tables_in_use: 0
trx_tables_locked: 0
trx_lock_structs: 2
trx_lock_memory_bytes: 376
trx_rows_locked: 1
trx_rows_modified: 1
trx_concurrency_tickets: 0
trx_isolation_level: REPEATABLE READ
trx_unique_checks: 1
trx_foreign_key_checks: 1
trx_last_foreign_key_error: NULL
trx_adaptive_hash_latched: 0
trx_adaptive_hash_timeout: 10000
1 row in set (1.02 sec)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
第三步：在另一会话中更新该记录，产生锁等待；

start transaction;
update tx1 set c1=‘heyfffff‘,c2=‘heyffffff‘,c3=SYSDATE()
where id =3 ;
1
2
3
查看innodb_trx表数据：

mysql> select * from information_schema.innodb_trx\G;
*************************** 1. row ***************************
trx_id: 75E35
trx_state: LOCK WAIT##事务状态
trx_started: 2018-06-06 17:02:33
trx_requested_lock_id: 75E35:0:7509:5
trx_wait_started: 2018-06-06 17:02:33
trx_weight: 2
trx_mysql_thread_id: 238
trx_query: update tx1 set c1=‘heyfffff‘,c2=‘heyffffff‘,c3=SYSDATE() where id =3
trx_operation_state: starting index read
trx_tables_in_use: 1
trx_tables_locked: 1
trx_lock_structs: 2
trx_lock_memory_bytes: 376
trx_rows_locked: 1
trx_rows_modified: 0
trx_concurrency_tickets: 0
trx_isolation_level: REPEATABLE READ
trx_unique_checks: 1
trx_foreign_key_checks: 1
trx_last_foreign_key_error: NULL
trx_adaptive_hash_latched: 0
trx_adaptive_hash_timeout: 10000
*************************** 2. row ***************************
trx_id: 75E34
trx_state: RUNNING##事务状态
trx_started: 2018-06-06 16:55:37
trx_requested_lock_id: NULL
trx_wait_started: NULL
trx_weight: 3
trx_mysql_thread_id: 235
trx_query: NULL
trx_operation_state: NULL
trx_tables_in_use: 0
trx_tables_locked: 0
trx_lock_structs: 2
trx_lock_memory_bytes: 376
trx_rows_locked: 1
trx_rows_modified: 1
trx_concurrency_tickets: 0
trx_isolation_level: REPEATABLE READ
trx_unique_checks: 1
trx_foreign_key_checks: 1
trx_last_foreign_key_error: NULL
trx_adaptive_hash_latched: 0
trx_adaptive_hash_timeout: 10000
2 rows in set (0.00 sec)
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
查看INNODB_LOCKS表数据：

mysql> select * from information_schema.INNODB_LOCKS\G;
*************************** 1. row ***************************
lock_id: 75E35:0:7509:5
lock_trx_id: 75E35
lock_mode: X
lock_type: RECORD
lock_table: `test`.`tx1`
lock_index: `PRIMARY`
lock_space: 0
lock_page: 7509
lock_rec: 5
lock_data: 3
*************************** 2. row ***************************
lock_id: 75E34:0:7509:5
lock_trx_id: 75E34
lock_mode: X
lock_type: RECORD
lock_table: `test`.`tx1`
lock_index: `PRIMARY`
lock_space: 0
lock_page: 7509
lock_rec: 5
lock_data: 3
2 rows in set (0.00 sec)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
查看INNODB_LOCK_WAITS表数据：

mysql> select * from information_schema.INNODB_LOCK_WAITS;\G
*************************** 1. row ***************************
requesting_trx_id: 75E35 ## 请求锁的事务
requested_lock_id: 75E35:0:7509:5 ## 请求锁的锁ID
blocking_trx_id: 75E34 ## 拥有锁的事务
blocking_lock_id: 75E34:0:7509:5 ## 拥有锁的锁ID
1
2
3
4
5
6
在执行第二个update的时候，由于第一个update事务还未提交，故而第二个update在等待，其事务状态为LOCK WAIT ，等待时间超过innodb_lock_wait_timeout值时，则会报ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction异常。

在第二个update锁等待超时之后，对第一个update手动提交事务，则第一个update语句成功更新数据库中数据表。

锁等待递进

如果是多个锁等待，比如有三个update，update同一行记录，则锁等待关系会层级递进，第二个第三个update都保留对第一个update的锁等待且第三个update保留对第二个update的锁等待，如下图：

【3】解决办法

① 查看并修改变量值

show GLOBAL VARIABLES like ‘%innodb_lock_wait_timeout%‘;

set GLOBAL innodb_lock_wait_timeout=100;##设置大小值看系统情况
1
2
3
innodb_lock_wait_timeout指的是事务等待获取资源等待的最长时间，超过这个时间还未分配到资源则会返回应用失败。参数的时间单位是秒，默认值50S。

② 找到一直未提交事务导致后来进程死锁等待的进程，并杀掉

根据锁等待表中的拥有锁的事务id(blocking_trx_id)，从innodb_trx表中找到trx_mysql_thread_id值，kill掉。

如 这里杀掉 进程235：

select trx_mysql_thread_id from information_schema.innodb_trx it
JOIN information_schema.INNODB_LOCK_WAITS ilw
on ilw.blocking_trx_id = it.trx_id;

##trx_mysql_thread_id: 235

kill 235
③ 优化SQL，优化数据库，优化项目。第一个update未执行完，第二个update就来了，超过等待时间就会报锁等待超时异常。在数据并发项目遇到这种情况概率比较大，这时候就要从项目、数据库、执行SQL多方面入手了。
————————————————
版权声明：本文为CSDN博主「流烟默」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/J080624/article/details/80596958

原文地址：https://www.cnblogs.com/qcfeng/p/11833625.html

时间： 2024-10-16 01:42:59

MySQL - 锁等待超时与information_schema的三个表的相关文章

MySQL锁等待分析【2】

MySQL锁等待分析[1]中对锁等待的分析是一步一步来的.虽然最后是分析出来了,可是用时是比较长的:理清各个表之间的关系后,得到如下SQL语句,方便以后使用 select block_trx.trx_mysql_thread_id as blocking_session_id, -- 已经持有锁的session ID request_trx.trx_mysql_thread_id as request_session_id, -- 正在申请锁的session ID block_trx.trx_q

查询MySQL锁等待的语句

select 'Blocker' role,    p.id,    p.user,    left(p.host, locate(':', p.host) - 1) host,    tx.trx_id,    tx.trx_state,    tx.trx_started, timestampdiff(second, tx.trx_started, now()) duration, lo.lock_mode, lo.lock_type, lo.lock_table, lo.lock_inde

mysql锁知识小了解

一.概述 mysql的锁分为表锁和行锁两种,其中myisam引擎用的是表锁, innoDB默认的使用是行锁, 其他情况是表锁. 两种锁的优缺点: 表级锁:加锁速度快,开销小.不会出现死锁的情况,粒度大,发生锁冲突的概率最高,并发度最低. 行级锁:加锁速度慢,开销大. 会出现死锁的情况,粒度小, 发生锁冲突的概率最小,并发度最高 页面锁:介于以上两者之间 无法确定哪种锁更合适: 表级锁更适合查询为主,只有少量按索引更新数据的应用,如web应用. 行级锁适合有大量索引并发更新少量不同的数据,同时有并

Mysql 锁机制和事务

InnoDB 锁机制 InnoDB存储引擎支持行级锁 其大类可以细分为共享锁和排它锁两类 共享锁(S):允许拥有共享锁的事务读取该行数据.当一个事务拥有一行的共享锁时,另外的事务可以在同一行数据也获得共享锁,但另外的事务无法获得同一行数据上的排他锁 排它锁(X):允许拥有排它锁的事务修改或删除该行数据. 当一个事务拥有一行的排他锁时,另外的事务在此行数据上无法获得共享锁和排它锁,只能等待第一个事务的锁释放 除了共享锁和排他锁之外, InnoDB也支持意图锁.该锁类型是属于表级锁,表明事务在后期会

排查MySQL事务没有提交导致 锁等待 Lock wait timeout exceeded

解决思路: select * from information_schema.innodb_trx 之后找到了一个一直没有提交的只读事务, kill 到了对应的线程后ok 了. 转载自:http://blog.sina.com.cn/s/blog_6bb63c9e0100s7cb.html 在Mysql5.5中,information_schema 库中增加了三个关于锁的表(MEMORY引擎): innodb_trx ## 当前运行的所有事务 innodb_locks ## 当前出现的锁 inn

zz 通过INFORMATION_SCHEMA.INNODB_TRX、INNODB_LOCKS、INNODB_LOCK_WAITS 三个表获取事务与锁的信息

zz from http://imysql.com/2015/03/25/mysql-faq-how-to-fetch-latest-trxid.shtml #先查询 INNODB_TRX 表,看看都有哪些事务 mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX\G *************************** 1. row *************************** trx_id: 17778 -- 当前事务ID trx_

mysql 开发进阶篇系列 13 锁问题(关于表锁，死锁示例，锁等待设置)

一. 什么时候使用表锁 对于INNODB表,在绝大部分情况下都应该使用行锁.在个别特殊事务中,可以考虑使用表锁(建议). 1. 事务需要更新大部份或全部数据,表又比较大,默认的行锁不仅使这个事务执行效率低,可能造成其他事务长时间锁等待和锁冲突,这种情况考虑使用表锁来提高事务的执行速度(具我在sql server中的经历,该大表有上100w,删除40w,表锁有时会造成长时间未执行完成. 还是使用分批来执行好). 2. 事务涉及多个表,比较复杂,很可能引起死锁,造成大量事务回滚.这种情况可以考虑一次

mysql外键引发的锁等待

有这样两条sql: insert table_a (bId) value(1); -- sql-1  update table_b set b.xx=123 where b.id =1; -- sql-2 其中,table_a的字段bId是个外键:外键关联的正是table_b的id字段. 在mysql上执行这两条数据时,sql-1会锁住sql-2.我们的系统中,为这一个锁,发生了不知道多少的锁等待,更引发了不知道多少的死锁. 特此备忘.

MySQL找出锁等待

1.服务器级别的锁等待可以通过show processlist看到等待锁的线程id,但是无法知道究竟哪个线程持有锁可以通过mysqladmin debug相关等待锁的线程以及谁持有锁可以在错误日志中找到 2.存储引擎层的锁等待则比较麻烦,以下是innodb存储引擎中锁等待以及哪个线程持有锁的查找sql SELECT r.trx_id AS waiting_trx_id, r.trx_mysql_thread_id AS waiting_thread, TIMESTAMPDIFF(SECOND,