MySQL死锁的详细分析方法

用数据库的时候，偶尔会出现死锁，针对我们的业务系统，出现死锁的直接结果就是系统卡顿，所以我们也在想尽全力的消除掉数据库的死锁。

出现死锁的时候，如果只是想解锁，用show full processlist看下kill掉就好了，如果想查找到详细的问题，一个办法是用show engine innodb status来查看简略信息或者开死锁日志，后期在MySQL日志里面慢慢分析。

以上这些方法我们都用过，最近在看Innodb的书的时候发现另一种实时的分析方法，能最大限度的分析死锁的原因。

MySQL 5.5版本以后，information_schema库中新增了三个关于锁的表：

innodb_trx: 记录当前运行的所有事务。
innodb_locks: 记录当前出现的锁。
innodb_lock_waits: 记录锁等待的对应关系。

下面对innodb_trx表的每个字段进行解释：

字段	描述
trx_id	事务ID
trx_state	事务状态，有以下几种状态：running、lock wait、rolling back和committing
trx_started	事务开始时间
trx_requested_lock_id	事务当前正在等待锁的标识。可以和INNODB_LOCKS表JOIN以得到更多详细信息
trx_wait_started	事务开始等待的时间
trx_weight	事务的权重
trx_mysql_thread_id	事务线程ID。可以和PROCESSLIST表JOIN
trx_query	事务正在执行的SQL语句
trx_operation_state	事务当前操作状态
trx_tables_in_use	当前事务执行的SQL中使用的表的个数
trx_tables_locked	当前执行SQL的行锁数量
trx_lock_structs	事务保留的锁数量
trx_lock_memory_bytes	事务锁住的内存大小，单位为bytes
trx_rows_locked	事务锁住的记录数，包含标记为deleted，并且已经保存到磁盘但对事务不可见的行
trx_rows_modified	事务更改的行数
trx_concurrency_tickets	事务并发票数
trx_isolation_level	当前事务的隔离级别
trx_unique_checks	是否打开唯一性检查的标识
trx_foreign_key_checks	是否打开外键检查的标识
trx_last_foreign_key_error	最后一次的外键错误信息
trx_adaptive_hash_latched	自适应散列索引是否被当前事务锁住的标识
trx_adaptive_hash_timeout	是否立刻放弃为自适应散列索引搜索LATCH的标识

下面对innodb_locks表的每个字段进行解释：

字段	描述
lock_id	锁ID
lock_trx_id	拥有锁的事务ID。可以和INNODB_TRX表JOIN得到事务的详细信息
lock_mode	锁的模式。有如下锁类型：行级锁包括：S、X、IS、IX，分别代表：共享锁、排它锁、意向共享锁、意向排它锁。表级锁包括：S_GAP、X_GAP、IS_GAP、IX_GAP和AUTO_INC，分别代表共享间隙锁、排它间隙锁、意向共享间隙锁、意向排它间隙锁和自动递增锁
lock_type	锁的类型。 RECORD代表行级锁，TABLE代表表级锁
lock_table	被锁定的或者包含锁定记录的表的名称
lock_index	当LOCK_TYPE=’RECORD’时，表示索引的名称；否则为NULL
lock_space	当LOCK_TYPE=’RECORD’时，表示锁定行的表空间ID；否则为NULL
lock_page	当LOCK_TYPE=’RECORD’时，表示锁定行的页号；否则为NULL
lock_rec	当LOCK_TYPE=’RECORD’时，表示一堆页面中锁定行的数量，亦即被锁定的记录号；否则为NULL
lock_data	当LOCK_TYPE=’RECORD’时，表示锁定行的主键；否则为NULL

查看innodb_lock_waits表结构。

字段	描述
requesting_trx_id	请求事务的ID
requested_lock_id	事务所等待的锁定的ID。可以和INNODB_LOCKS表JOIN
blocking_trx_id	阻塞事务的ID
blocking_lock_id	某一事务的锁的ID，该事务阻塞了另一事务的运行。可以和INNODB_LOCKS表JOIN

新建一个锁事务进行模拟一下。

Session1开始事务。

mysql> START TRANSACTION;

Query OK, 0 rows affected (0.00 sec)

mysql> UPDATE user SET name='wentasy' WHERE id = 2;

Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0
-- 此时已经开始事务，所以innodb_trx表会有记录。

mysql> SELECT * FROM information_schema.innodb_trx \G;

*************************** 1. row ***************************
trx_id: 360E
trx_state: RUNNING
trx_started: 2015-01-27 15:23:49
trx_requested_lock_id: NULL
trx_wait_started: NULL
trx_weight: 3
trx_mysql_thread_id: 1
trx_query: SELECT * FROM information_schema.innodb_trx
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 (0.00 sec)

-- 此时没有发生锁等待，故innodb_locks表和innodb_lock_waits表都没有数据。
mysql> SELECT * FROM information_schema.innodb_locks \G;
Empty set (0.00 sec)

mysql> SELECT * FROM information_schema.innodb_lock_waits \G;
Empty set (0.00 sec)

Session2更新数据。

mysql> USE test;
mysql> UPDATE user SET name="lock_waits" WHERE ID = 2;

Session1查看innodb_trx表、innodb_locks表和innodb_lock_waits表，可以查看到数据。

在innodb_trx表的第一行，trx_id为360F表示第二个事务，状态为等待状态，请求的锁ID为360F:243:3:3，线程ID为2，事务用到的表为1，有1个表被锁。第二行中，trx_id为360E表示第一个事务。

mysql> SELECT * FROM information_schema.innodb_trx \G;

*************************** 1. row ***************************
trx_id: 360F
trx_state: LOCK WAIT
trx_started: 2015-01-27 15:28:48
trx_requested_lock_id: 360F:243:3:3
trx_wait_started: 2015-01-27 15:28:48
trx_weight: 2
trx_mysql_thread_id: 2
trx_query: UPDATE user SET name="lock_waits" WHERE ID = 2
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: 360E
trx_state: RUNNING
trx_started: 2015-01-27 15:23:49
trx_requested_lock_id: NULL
trx_wait_started: NULL
trx_weight: 3
trx_mysql_thread_id: 1
trx_query: SELECT * FROM information_schema.innodb_trx
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)

mysql> SELECT * FROM information_schema.innodb_locks \G;

*************************** 1. row ***************************
lock_id: 360F:243:3:3
lock_trx_id: 360F
lock_mode: X
lock_type: RECORD
lock_table: `test`.`user`
lock_index: `PRIMARY`
lock_space: 243
lock_page: 3
lock_rec: 3
lock_data: 2

*************************** 2. row ***************************
lock_id: 360E:243:3:3
lock_trx_id: 360E
lock_mode: X
lock_type: RECORD
lock_table: `test`.`user`
lock_index: `PRIMARY`
lock_space: 243
lock_page: 3
lock_rec: 3
lock_data: 2

2 rows in set (0.00 sec)

mysql> SELECT * FROM information_schema.innodb_lock_waits \G;

*************************** 1. row ***************************
requesting_trx_id: 360F
requested_lock_id: 360F:243:3:3
blocking_trx_id: 360E
blocking_lock_id: 360E:243:3:

1 row in set (0.00 sec)

由于默认的innodb_lock_wait_timeout是50秒，所以50秒过后，Session2出现如下提示：

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction】

posted @ 2022-04-26 09:43 夏尔_717 阅读(487) 评论(0) 编辑收藏举报

刷新页面返回顶部

ciel_717

MySQL死锁的详细分析方法

公告