在 MySQL 运维过程中，难免会碰着 MySQL 去世锁的情形，一旦线上业务日渐繁芜，各种业务操作之间每每会产生锁冲突，有些会导致去世锁非常。这种去世锁非常一样平常要在特定时间特天命据和特定业务操作才会复现，有时候处理起来毫无头绪，一样平常只能从去世锁日志下手。本篇文章我们一起来看下 MySQL 的去世锁日志。
1.手动打印去世锁日志当业务发生去世锁时，首先是线上缺点日志报警创造去世锁非常，也会提示一些堆栈信息，然后会反馈到数据库层面进行排查。我们一样平常会在命令行实行 show engine innodb status\G 来输出去世锁日志，\G 的浸染是将查询到的结果，每行显示一个字段和字段值，方便查看。
show engine innodb status 是 MySQL 供应的一个用于查看 innodb 引擎系统信息的工具。它会输出大量的内部信息，内容分为很多小段，每一段对应 innodb 存储引擎不同部分的信息，个中 LATEST DETECTED DEADLOCK 部分显示的最近一次的去世锁信息。
下面我们手动制造一次去世锁，来看一下去世锁日志干系信息：
------------------------LATEST DETECTED DEADLOCK------------------------2021-11-10 17:03:10 0x7fb040672700 (1) TRANSACTION:TRANSACTION 46913, ACTIVE 142 sec starting index readmysql tables in use 1, locked 1LOCK WAIT 4 lock struct(s), heap size 1136, 3 row lock(s), undo log entries 1MySQL thread id 2997198, OS thread handle 140394973071104, query id 9145673 localhost root updatingupdate test_tb set stu_name = 'lisi' where stu_id = 1006 (1) WAITING FOR THIS LOCK TO BE GRANTED:RECORD LOCKS space id 224 page no 4 n bits 80 index uk_stu_id of table `testdb`.`test_tb` trx id 46913 lock_mode X locks rec but not gap waitingRecord lock, heap no 7 PHYSICAL RECORD: n_fields 2; compact format; info bits 0 0: len 4; hex 800003ee; asc ;; 1: len 4; hex 80000006; asc ;; (2) TRANSACTION:TRANSACTION 46914, ACTIVE 103 sec starting index readmysql tables in use 1, locked 14 lock struct(s), heap size 1136, 3 row lock(s), undo log entries 1MySQL thread id 2997201, OS thread handle 140394971473664, query id 9145681 localhost root updatingupdate test_tb set age = 21 where stu_id = 1005 (2) HOLDS THE LOCK(S):RECORD LOCKS space id 224 page no 4 n bits 80 index uk_stu_id of table `testdb`.`test_tb` trx id 46914 lock_mode X locks rec but not gapRecord lock, heap no 7 PHYSICAL RECORD: n_fields 2; compact format; info bits 0 0: len 4; hex 800003ee; asc ;; 1: len 4; hex 80000006; asc ;; (2) WAITING FOR THIS LOCK TO BE GRANTED:RECORD LOCKS space id 224 page no 4 n bits 80 index uk_stu_id of table `testdb`.`test_tb` trx id 46914 lock_mode X locks rec but not gap waitingRecord lock, heap no 6 PHYSICAL RECORD: n_fields 2; compact format; info bits 0 0: len 4; hex 800003ed; asc ;; 1: len 4; hex 80000005; asc ;; WE ROLL BACK TRANSACTION (2)# 以上为原文 下面增加个人剖析------------------------LATEST DETECTED DEADLOCK------------------------2021-11-10 17:03:10 0x7fb040672700 #这里显示了最近一次发生去世锁的日期和韶光 (1) TRANSACTION: #去世锁干系的第一个事务TRANSACTION 46913, ACTIVE 142 sec starting index read#这行表示事务id为46913，事务处于生动状态142s，starting index read表示正在利用索引读取数据行mysql tables in use 1, locked 1#这行表示该事务正在利用1个表，且涉及锁的表有1个LOCK WAIT 4 lock struct(s), heap size 1136, 3 row lock(s), undo log entries 1#这行表示在等待4把锁，占用内存1136字节，涉及3行记录MySQL thread id 2997198, OS thread handle 140394973071104, query id 9145673 localhost root updating#这行表示该事务的线程ID信息，操作系统句柄信息，连接来源、用户update test_tb set stu_name = 'lisi' where stu_id = 1006#这行表示事务实行的末了一条SQL信息 (1) WAITING FOR THIS LOCK TO BE GRANTED: #事务1想要获取的锁RECORD LOCKS space id 224 page no 4 n bits 80 index uk_stu_id of table `testdb`.`test_tb` trx id 46913 lock_mode X locks rec but not gap waiting#这行信息表示等待的锁是一个record lock，空间id是224，页编号为4，大概位置在页的80位处，锁发生在表testdb.test_tb的uk_stu_id索引上，是一个X锁，但是不是gap lock，waiting表示正在等待锁Record lock, heap no 7 PHYSICAL RECORD: n_fields 2; compact format; info bits 0 0: len 4; hex 800003ee; asc ;; 1: len 4; hex 80000006; asc ;; (2) TRANSACTION: #去世锁干系的第一个事务TRANSACTION 46914, ACTIVE 103 sec starting index read#这行表示事务2的id为46914，事务处于生动状态103smysql tables in use 1, locked 1#正在利用1个表，涉及锁的表有1个4 lock struct(s), heap size 1136, 3 row lock(s), undo log entries 1#涉及4把锁，3行记录MySQL thread id 2997201, OS thread handle 140394971473664, query id 9145681 localhost root updating#事务2的线程ID信息，操作系统句柄信息，连接来源、用户update test_tb set age = 21 where stu_id = 1005#第二个事务的SQL (2) HOLDS THE LOCK(S): # 事务2持有的锁 正是事务1想要获取的锁RECORD LOCKS space id 224 page no 4 n bits 80 index uk_stu_id of table `testdb`.`test_tb` trx id 46914 lock_mode X locks rec but not gapRecord lock, heap no 7 PHYSICAL RECORD: n_fields 2; compact format; info bits 0 0: len 4; hex 800003ee; asc ;; 1: len 4; hex 80000006; asc ;; (2) WAITING FOR THIS LOCK TO BE GRANTED:RECORD LOCKS space id 224 page no 4 n bits 80 index uk_stu_id of table `testdb`.`test_tb` trx id 46914 lock_mode X locks rec but not gap waitingRecord lock, heap no 6 PHYSICAL RECORD: n_fields 2; compact format; info bits 0 0: len 4; hex 800003ed; asc ;; 1: len 4; hex 80000005; asc ;;#上面这部分是事务二正在等待的锁，从信息上看，等待的是同一个表，同一个索引，同一个page上的record lock X锁，但是heap no位置不同，即不同的行上的锁 WE ROLL BACK TRANSACTION (2) #表示事务2被回滚
从去世锁日志中可以看到关联的两个事务干系信息，当一个事务持有了其他事务须要的锁，同时又想得到其他事务持有的锁时，等待关系上就会产生循环，Innodb 不会显示所有持有和等待的锁，但去世锁日志也显示了干系的信息来帮你确定，排查去世锁发生的索引，这对付你确定能否避免去世锁有较大的代价。
2.自动保存去世锁日志从上面内容我们知道 MySQL 的去世锁可以通过 show engine innodb status 来查看，但是这个命令须要手动实行并且只能显示最新的一条去世锁，该办法无法完备捕获到系统发生的去世锁信息。那有没有办法记录所有的去世锁日志呢，我们来看下 MySQL 的系统参数。
MySQL 系统内部供应一个 innodb_print_all_deadlocks 参数，该参数默认是关闭的，开启后可以将去世锁信息自动记录到 MySQL 的缺点日志中。下面我们来看下这个参数的浸染：
# 查看参数是否开启mysql> show variables like 'innodb_print_all_deadlocks';+----------------------------+-------+| Variable_name | Value |+----------------------------+-------+| innodb_print_all_deadlocks | OFF |+----------------------------+-------+# 开启innodb_print_all_deadlocks,此参数是全局参数，可以动态调度。记得要加入到配置文件中mysql> set global innodb_print_all_deadlocks = 1;Query OK, 0 rows affected (0.00 sec)mysql> show variables like 'innodb_print_all_deadlocks';+----------------------------+-------+| Variable_name | Value |+----------------------------+-------+| innodb_print_all_deadlocks | ON |+----------------------------+-------+
建议将 innodb_print_all_deadlocks 参数设置为 1 ，这样每次发生去世锁后，系统会自动将去世锁信息输出到缺点日志中，须要把稳的是打开此参数后，只会记录去世锁部分信息而不会记录 innodb 其他干系信息，即只会记录 show engine innodb status 中的 LATEST DETECTED DEADLOCK 部分。
实在 InnoDB 存储引擎还供应有 InnoDB Monitor 监视器，可以定期将 InnoDB 的状态信息输出到缺点日志中，紧张由 innodb_status_output 和 innodb_status_output_locks 参数掌握，这两个别系变量是用来启用标准 InnoDB 监控和 InnoDB 锁监控的，开启后会将监控结果输出错误日志中，大约每隔 15 秒产生一次输出，输出内容与 show engine innodb status 同等。不过这会导致缺点日志暴增，一样平常不建议开启这两个参数。
总结：
本篇文章先容了 MySQL 去世锁日志的获取方法，发生去世锁后，可以根据去世锁日志还获取干系信息。开启 innodb_print_all_deadlocks 参数可以自动将去世锁信息输出到缺点日志中，有助于我们及时创造并处理去世锁非常。
