如何查看MySQL数据库的死锁信息

查看MySQL数据库的死锁日志

1. 使用终端或命令提示符登录到MySQL，输入命令：mysql -h xxxx.xxx.xxx -P 3306 -u username -p 解释：xxxx.xxx.xxx是数据库IP地址，username是数据库用户名，输入命令后，会让你输入username对应的密码，就可以登录了

2. 如何查看MySQL数据库的死锁信息 在MySQL客户端下输入命令： show engine innodb status \G

3. 如何定位MySQL数据库的死锁信息 在打印出来的信息中找到“LATEST DETECTED DEADLOCK”一节内容，看图中红线

4. 如何分析日志，定位死锁原因 看3里面的图，紫色划线部分 分析： 事务1，等待 RECORD LOCKS space id 553 page no 376 n bits 368 index `index_user_id` of table `tbj`.`score_user`，这个位置的X锁 事务2，持有 RECORD LOCKS space id 553 page no 376 n bits 368 index `index_user_id` of table `tbj`.`score_user`这个地方的S锁 事务2，等待这个地方的X锁 理论上这个事务2是可以提交的不会，死锁，但是这个事务日志只打印最后一部分死锁，信息，这里面隐含的条件是，事务1也持有 RECORD LOCKS space id 553 page no 376 n bits 368 index `index_user_id` of table `tbj`.`score_user`这个地方的S锁，这样，事务2不能加X锁，同时事务1也不能加X锁，产生死锁。

这是我见的一个文档，虽然我看不懂，你看看有没有帮助

MySQL死锁问题的相关知识是本文我们主要要介绍的内容，接下来我们就来一一介绍这部分内容，希望能够对您有所帮助。

1、MySQL常用存储引擎的锁机制

MyISAM和MEMORY采用表级锁(table-level locking)

BDB采用页面锁(page-level locking)或表级锁，默认为页面锁

InnoDB支持行级锁(row-level locking)和表级锁，默认为行级锁

2、各种锁特点

表级锁：开销小，加锁快不会出现死锁锁定粒度大，发生锁冲突的概率最高，并发度最低

行级锁：开销大，加锁慢会出现死锁锁定粒度最小，发生锁冲突的概率最低，并发度也最高

页面锁：开销和加锁时间界于表锁和行锁之间会出现死锁锁定粒度界于表锁和行锁之间，并发度一般

3、各种锁的适用场景

表级锁更适合于以查询为主，只有少量按索引条件更新数据的应用，如Web应用

行级锁则更适合于有大量按索引条件并发更新数据，同时又有并发查询的应用，如一些在线事务处理系统

4、死锁

是指两个或两个以上的进程在执行过程中，因争夺资源而造成的一种互相等待的现象，若无外力作用，它们都将无法推进下去。

表级锁不会产生死锁。所以解决死锁主要还是针对于最常用的InnoDB。

5、死锁举例分析

在MySQL中，行级锁并不是直接锁记录，而是锁索引。索引分为主键索引和非主键索引两种，如果一条sql语句 *** 作了主键索引，MySQL就会锁定这条主键索引如果一条语句 *** 作了非主键索引，MySQL会先锁定该非主键索引，再锁定相关的主键索引。

在UPDATE、DELETE *** 作时，MySQL不仅锁定WHERE条件扫描过的所有索引记录，而且会锁定相邻的键值，即所谓的next-key locking。

例如，一个表db。tab_test，结构如下：

id：主键

state：状态

time：时间

索引：idx_1(state，time)

出现死锁日志如下：

?***(1) TRANSACTION:

?TRANSACTION 0 677833455, ACTIVE 0 sec, process no 11393, OSthread id 278546 starting index read

?mysql tables in use 1, locked 1

?LOCK WAIT 3 lock struct(s), heap size 320

?MySQL thread id 83, query id 162348740 dcnet03 dcnet Searching rows for update

?update tab_test set state=1064,time=now() where state=1061 and time <date_sub(now(), INTERVAL 30 minute) (任务1的sql语句)

?***(1) WAITING FOR THIS LOCK TO BE GRANTED: (任务1等待的索引记录)

?RECORD LOCKS space id 0 page no 849384 n bits 208 index `PRIMARY` of table `db/tab_test` trx id 0 677833455 _mode X locks rec but not gap waiting

?Record lock, heap no 92 PHYSICAL RECORD: n_fields 11compact formatinfo bits 0

?0: len 8hex 800000000097629casc b 1: len 6hex 00002866eaeeasc (f 2: len 7hex 00000d40040110asc @ 3: len 8hex 80000000000050b2asc P 4: len 8hex 800000000000502aasc P*5: len 8hex 8000000000005426asc T&6: len 8hex 800012412c66d29casc A,f 7: len 23hex 75706c6f6164666972652e636f6d2f6 8616e642e706870asc xxx.com/8: len 8hex 800000000000042basc +9: len 4hex 474bfa2basc GK +10: len 8hex 8000000000004e24asc N$

?*** (2) TRANSACTION:

?TRANSACTION 0 677833454, ACTIVE 0 sec, process no 11397, OS thread id 344086 updating or deleting, thread declared inside InnoDB 499

?mysql tables in use 1, locked 1

?3 lock struct(s), heap size 320, undo log entries 1

?MySQL thread id 84, query id 162348739 dcnet03 dcnet Updating update tab_test set state=1067,time=now () where id in (9921180) (任务2的sql语句)

?*** (2) HOLDS THE LOCK(S): (任务2已获得的锁)

?RECORD LOCKS space id 0 page no 849384 n bits 208 index `PRIMARY` of table `db/tab_test` trx id 0 677833454 lock_mode X locks rec but not gap

?Record lock, heap no 92 PHYSICAL RECORD: n_fields 11compact formatinfo bits 0

?0: len 8hex 800000000097629casc b 1: len 6hex 00002866eaeeasc (f 2: len 7hex 00000d40040110asc @ 3: len 8hex 80000000000050b2asc P 4: len 8hex 800000000000502aasc P*5: len 8hex 8000000000005426asc T&6: len 8hex 800012412c66d29casc A,f 7: len 23hex 75706c6f6164666972652e636f6d2f6 8616e642e706870asc uploadfire.com/hand.php8: len 8hex 800000000000042basc +9: len 4hex 474bfa2basc GK +10: len 8hex 8000000000004e24asc N$

?*** (2) WAITING FOR THIS LOCK TO BE GRANTED: (任务2等待的锁)

?RECORD LOCKS space id 0 page no 843102 n bits 600 index `idx_1` of table `db/tab_test` trx id 0 677833454 lock_mode X locks rec but not gap waiting

?Record lock, heap no 395 PHYSICAL RECORD: n_fields 3compact formatinfo bits 0

?0: len 8hex 8000000000000425asc %1: len 8hex 800012412c66d29casc A,f 2: len 8hex 800000000097629casc b

?*** WE ROLL BACK TRANSACTION (1)

?(回滚了任务1，以解除死锁)

原因分析：

当“update tab_test set state=1064,time=now() where state=1061 and time <date_sub(now(), INTERVAL 30 minute)”执行时，MySQL会使用idx_1索引，因此首先锁定相关的索引记录，因为idx_1是非主键索引，为执行该语句，MySQL还会锁定主键索引。

假设“update tab_test set state=1067,time=now () where id in (9921180)”几乎同时执行时，本语句首先锁定主键索引，由于需要更新state的值，所以还需要锁定idx_1的某些索引记录。

这样第一条语句锁定了idx_1的记录，等待主键索引，而第二条语句则锁定了主键索引记录，而等待idx_1的记录，这样死锁就产生了。

6、解决办法

拆分第一条sql，先查出符合条件的主键值，再按照主键更新记录：

?select id from tab_test where state=1061 and time <date_sub(now(), INTERVAL 30 minute)

?update tab_test state=1064,time=now() where id in(......)

当多个用户访问同一份数据时，一个用户在更改数据的过程中，可能有其他用户同时发起更改请求，为保证数据库记录的更新从一个一致性状态变为另外一个一致性状态，使用事务处理是非常必要的，事务具有以下四个特性：

MySQL 提供了多种事务型存储引擎，如 InnoDB 和 BDB 等，而 MyISAM 不支持事务。为了支持事务，InnoDB 存储引擎引入了与事务处理相关的 REDO 日志和 UNDO 日志，同时事务依赖于 MySQL 提供的锁机制

事务执行时需要将执行的事务日志写入日志文件，对应的文件为 REDO 日志。当每条 SQL 进行数据更新 *** 作时，首先将 REDO 日志写进日志缓冲区。当客户端执行 COMMIT 命令提交时，日志缓冲区的内容将被刷新到磁盘，日志缓冲区的刷新方式或者时间间隔可以通过参数 innodb_flush_log_at_trx_commit 控制

REDO 日志对应磁盘上的 ib_logifleN 文件，该文件默认为 5MB，建议设置为 512MB，以便容纳较大的事务。MySQL 崩溃恢复时会重新执行 REDO 日志的记录，恢复最新数据，保证已提交事务的持久性

与 REDO 日志相反，UNDO 日志主要用于事务异常时的数据回滚，具体内容就是记录数据被修改前的信息到 UNDO 缓冲区，然后在合适的时间将内容刷新到磁盘

假如由于系统错误或者 rollback *** 作而导致事务回滚，可以根据 undo 日志回滚到没修改前的状态，保证未提交事务的原子性

与 REDO 日志不同的是，磁盘上不存在单独的 UNDO 日志文件，所有的 UNDO 日志均存在表空间对应的 .ibd 数据文件中，即使 MySQL 服务启动了独立表空间

在 MySQL 中，可以使用 BEGIN 开始事务，使用 COMMIT 结束事务，中间可以使用 ROLLBACK 回滚事务。MySQL 通过 SET AUTOCOMMIT、START TRANSACTION、COMMIT 和 ROLLBACK 等语句支持本地事务

MySQL 定义了四种隔离级别，指定事务中哪些数据改变其他事务可见、哪些数据该表其他事务不可见。低级别的隔离级别可以支持更高的并发处理，同时占用的系统资源更少

InnoDB 系统级事务隔离级别可以使用以下语句设置：

查看系统级事务隔离级别：

InnoDB 会话级事务隔离级别可以使用以下语句设置：

查看会话级事务隔离级别：

在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。读取未提交的数据称为脏读（Dirty Read），即是：首先开启 A 和 B 两个事务，在 B 事务更新但未提交之前，A 事务读取到了更新后的数据，但由于 B 事务回滚，导致 A 事务出现了脏读现象

所有事务只能看见已经提交事务所做的改变，此级别可以解决脏读，但也会导致不可重复读（Nonrepeatable Read）：首先开启 A 和 B 两个事务，A事务读取了 B 事务的数据，在 B 事务更新并提交后，A 事务又读取到了更新后的数据，此时就出现了同一 A 事务中的查询出现了不同的查询结果

MySQL 默认的事务隔离级别，能确保同一事务的多个实例在并发读取数据时看到同样的数据行，理论上会导致一个问题，幻读（Phontom Read）。例如，第一个事务对一个表中的数据做了修改，这种修改会涉及表中的全部数据行，同时第二个事务也修改这个表中的数据，这次的修改是向表中插入一行新数据，此时就会发生 *** 作第一个事务的用户发现表中还有没有修改的数据行

InnoDB 通过多版本并发控制机制（MVCC）解决了该问题：InnoDB 通过为每个数据行增加两个隐含值的方式来实现，这两个隐含值记录了行的创建时间、过期时间以及每一行存储时间发生时的系统版本号，每个查询根据事务的版本号来查询结果

通过强制事务排序，使其不可能相互冲突，从而解决幻读问题。简而言之，就是在每个读的数据行上加上共享锁实现，这个级别会导致大量的超时现象和锁竞争，一般不推荐使用

为了解决数据库并发控制问题，如走到同一时刻客户端对同一张表做更新或者查询 *** 作，需要对并发 *** 作进行控制，因此产生了锁

共享锁的粒度是行或者元组（多个行），一个事务获取了共享锁以后，可以对锁定范围内的数据执行读 *** 作

排他锁的粒度与共享锁相同，一个事务获取排他锁以后，可以对锁定范围内的数据执行写 *** 作

有两个事务 A 和 B，如果事务 A 获取了一个元组的共享锁，事务 B 还可以立即获取这个元组的共享锁，但不能获取这个元组的排他锁，必须等到事务 A 释放共享锁之后。如果事务 A 获取了一个元组的排他锁，事务 B 不能立即获取这个元组的共享锁，也不能立即获取这个元组的排他锁，必须等到 A 释放排他锁之后

意向锁是一种表锁，锁定的粒度是整张表，分为意向共享锁和意向排他锁。意向共享锁表示一个事务有意对数据上共享锁或者排他锁。有意表示事务想执行 *** 作但还没真正执行

锁的粒度主要分为表锁和行锁

表锁的开销最小，同时允许的并发量也是最小。MyISAM 存储引擎使用该锁机制。当要写入数据时，整个表记录被锁，此时其他读/写动作一律等待。一些特定的动作，如 ALTER TABLE 执行时使用的也是表锁

行锁可以支持最大的并发，InnoDB 存储引擎使用该锁机制。如果要支持并发读/写，建议采用 InnoDB 存储引擎

---