简单介绍MySQL打印死锁日志的方法

最新推荐文章于 2025-06-03 14:18:32 发布
转载 最新推荐文章于 2025-06-03 14:18:32 发布 · 800 阅读 · 0 ·
CC 4.0 BY-SA版权
原文链接：https://www.linuxprobe.com/?p=235109
文章标签：

#mysql #数据库 #java

本文详细解读如何在MySQL中手动和自动获取死锁日志，包括通过showengineinnodbstatus命令查看死锁详情，以及设置innodb_print_all_deadlocks参数来自动记录死锁。通过实例解析死锁日志结构，帮助运维人员快速定位和解决死锁问题。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

导读本文主要介绍了MySQL打印死锁日志的方法步骤，文中通过示例代码介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们可以参考一下

前言：

在 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 read
mysql tables in use 1, locked 1
LOCK WAIT 4 lock struct(s), heap size 1136, 3 row lock(s), undo log entries 1
MySQL thread id 2997198, OS thread handle 140394973071104, query id 9145673 localhost root updating
update 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 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
mysql tables in use 1, locked 1
4 lock struct(s), heap size 1136, 3 row lock(s), undo log entries 1
MySQL thread id 2997201, OS thread handle 140394971473664, query id 9145681 localhost root updating
update 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 gap
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) 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 waiting
Record 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，事务处于活跃状态103s
mysql 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 gap
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) 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 waiting
Record 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 参数可以自动将死锁信息输出到错误日志中，有助于我们及时发现并处理死锁异常。www.linuxprobe.com

Linux资源站
关注
Java死锁情况下打印日志_通过JVM日志分析排查Java线程死锁
weixin_35992471的博客
03-01 880
通过JVM日志分析排查Java线程死锁两种办法：使用jstack 命令和jconsole工具1. jstack(1) 首先通过 jps 命令查看需要查看运行的Java进程列表，得到想查看的进程的id。(2)执行: jstack -l ：得到一些log，可以看到获取，释放，等待锁等log情况2. 使用jconsole: 命令行直接jconsole打开jconsole，这是个可视化的工具，可以查看：概...
mysql -h 日志打印_mysql —日志记录
weixin_32927369的博客
01-27 298
日志事务日志： transaction log中继日志： reley log错误日志： error log通用日志： general log慢查询日志： slow query log二进制日志： binary log事务日志transaction log：事务型存储引擎自行管理和使用在一个事务提交后还没有存到磁盘的情况下会记录到事务日志，这个时候如果系统断电，再次开机后会自动将已提交的事务重做(r...
mysql -h 日志打印_18.mysql日志
weixin_32841641的博客
02-17 516
在任何一种数据库中，都会有各种各样的日志，记录着数据库工作的方方面面，以帮助数据库管理员追踪数据库曾经发生过的各种事件。MySQL 也不例外，在 MySQL 中，有 4 种不同的日志，分别是错误日志、二进制日志(BINLOG 日志)、查询日志和慢查询日志，这些日志记录着数据库在不同方面的踪迹。1.错误日志错误日志是 MySQL 中最重要的日志之一，它记录了当 mysqld 启动和停止时，以及服务器...
MySQL死锁日志分析
Made In SQL
06-03 699
MySQL死锁日志分析指南摘要： MySQL死锁日志是诊断锁冲突的核心工具，包含事务ID、SQL语句、锁等待关系等关键信息。获取方式包括配置innodb_print_all_deadlocks参数和实时监控错误日志。日志分析需重点关注循环等待链和锁类型（记录锁/间隙锁），可通过绘制事务关系图直观展示死锁路径。解决方案包括：1)优化事务设计（固定资源访问顺序）；2)添加合适索引；3)使用乐观锁替代悲观锁；4)调整隔离级别。建议建立监控机制，通过PMM或Prometheus跟踪死锁指标。完整分析流程包含日志获取
innodb_print_all_deadlocks
huangliang0703的专栏
07-13 3850
当mysql 数据库发生死锁时， innodb status 里面会记录最后一次死锁的相关信息，但mysql 错误日志里面不会记录死锁相关信息，要想记录，启动 innodb_print_all_deadlocks  参数 mysql> show variables like 'innodb_print_all_deadlocks'; +----------------------------...
mysql打日志
qq_42903710的博客
09-25 225
https://www.cnblogs.com/xcsn/p/11485939.html
MySQL死锁问题如何排查?
java1234的博客
01-12 1044
MySQL死锁问题如何排查?
MySQL死锁产生的原因和解决方法
zhoupenghui168的博客
02-24 5641
线程安全问题以及MySQL死锁产生的原因和解决方法排查方法和案例分析
MySQL 8.0 日志配置管理
2402_86679690的博客
10-14 1345
MySQL 8.0 日志配置管理
mysql 查看锁表_面试官：mysql数据库怎么记录下曾发生死锁的语句？
weixin_39768917的博客
12-05 1102
概述死锁在平时工作中总是很常见，我们又不可能总是实时关注着，那么怎么去把发生死锁的一些情况记录下来呢？1、配置文件在MySQL 5.6版本中查看死锁，需要执行show engine innodb statusG;命令。在MySQL 5.6/5.7或MariaDB 10.0/10.1版本中，在my.cnf配置文件里加入：innodb_print_all_deadlocks=1 就可以把死锁信息打印到...
mysql日志打印
kerryg的专栏
11-06 1503
在D:\workspace\tools\wamp\bin\mysql\mysql5.5.20文件夹下的my.ini中增加
logging.basicConfig(level=logging.INFO)配置失效
weixin_39773337的博客
10-17 3495
问题： 在进行UI自动化时，想要输出每次查找元素的日志，引入logging模块，并设置logging.INFO，但是实际上运行正常，但控制台并没有输出日志： class BasePage: _driver = None _params={} _base_url = "" logging.basicConfig(level=logging.INFO) def __init__(self,driver:WebDriver = None): if driv
mysql -h 日志打印_mysql日志
weixin_31463861的博客
01-19 271
mysql日志查看mysql版本1. select version();2. status;1.错误日志错误日志文件位置:如果在配置文件中没有指定,则文件名为hostname.err可通过my.cnf文件进行配置[mysqld_safe]log-error=/var/log/mysql_err.log通过echo >/var/log/mysql_err.log 清空文件perror...
mysql死锁_详解MySQL（InnoDB）是如何处理死锁的
weixin_30848953的博客
01-18 396
一、什么是死锁官方定义如下：两个事务都持有对方需要的锁，并且在等待对方释放，并且双方都不会释放自己的锁。这个就好比你有一个人质，对方有一个人质，你们俩去谈判说换人。你让对面放人，对面让你放人。二、为什么会形成死锁看到这里，也许你会有这样的疑问，事务和谈判不一样，为什么事务不能使用完锁之后立马释放呢？居然还要操作完了之后一直持有锁？这就涉及到 MySQL 的并发控制了。MySQL的并发控制有两种方式...
mysql deadlock log_基于innodb_print_all_deadlocks从errorlog中解析MySQL死锁日志
weixin_35753291的博客
01-19 744
本文是说明如何获取死锁日志记录的，不是说明如何解决死锁问题的。MySQL的死锁可以通过show engine innodb status;来查看，但是show engine innodb status;只能显示最新的一条死锁，该方式无法完全捕获到系统发生的死锁信息。如果想要记录所有的死锁日志，打开innodb_print_all_deadlocks参数可以将所有的死锁日志记录到errorlog中，...
MySQL打印死锁日志
MySQL技术
11-15 1096
前言： 在 MySQL 运维过程中，难免会遇到 MySQL 死锁的情况，一旦线上业务日渐复杂，各种业务操作之间往往会产生锁冲突，有些会导致死锁异常。这种死锁异常一般要在特定时间特定数据和特定业务操作才会复现，有时候处理起来毫无头绪，一般只能从死锁日志下手。本篇文章我们一起来看下 MySQL 的死锁日志。 1.手动打印死锁日志 当业务发生死锁时，首先是线上错误日志报警发现死锁异常，也会提示一些堆栈信息，然后会反馈到数据库层面进行排查。我们一般会在命令行执行 show engine innodb status\
如何读懂MySQL死锁日志
一个技术菜鸟的博客
08-10 2106
测试环境： CREATE TABLE `test` ( `id` INT(10) NOT NULL, `str` VARCHAR(50), PRIMARY KEY (`id`), UNIQUE INDEX `str` (`str`) ) COLLATE='utf8_general_ci' ENGINE=InnoDB ; INSERT INTO `test` (`id`, `str`) VALUES (10234567, '1sdfsdfsdfsdfsdfsdfsdfsdfsdflkj;lkjlkh
如何解读MySQL死锁日志中的RECORD LOCKS信息？
最新发布
07-20
<think>我们正在分析MySQL死锁日志中的RECORD LOCKS部分。根据引用[1][2][3]，RECORD LOCKS是行锁（记录锁）的信息，它锁定了索引上的特定记录。以下是如何分析死锁日志中的RECORD LOCKS部分以定位死锁原因： ### 1. **理解RECORD LOCKS日志结构** 在`SHOW ENGINE INNODB STATUS`输出的死锁日志中，`RECORD LOCKS`部分通常包含以下关键信息： ``` RECORD LOCKS space id 0 page no 46 n bits 72 index PRIMARY of table `test`.`t1` trx id 246047 lock_mode X locks rec but not gap ``` - **space id**：表空间ID（0表示系统表空间）。 - **page no**：数据页编号（定位锁所在的物理页）。 - **n bits**：锁位图中的位数（用于管理锁的位图大小）。 - **index**：锁所在的索引（如`PRIMARY`表示主键索引，`idx_user_id`表示二级索引）。 - **table**：锁涉及的表（格式为`` `数据库名`.`表名` ``）。 - **trx id**：持有或等待锁的事务ID。 - **lock_mode**：锁模式，常见值： - `X`：排他锁（其他事务不能读写）。 - `S`：共享锁（其他事务可读不可写）。 - **锁范围类型**： - `locks rec but not gap`：仅锁定记录本身（记录锁）。 - `locks gap before rec`：锁定记录前的间隙（间隙锁）。 - `locks gap and rec`：锁定记录及间隙（临键锁）[^1][^2]。 ### 2. **分析死锁链** 死锁日志会展示两个事务（TRANSACTION 1和TRANSACTION 2）相互等待锁的情况： - **`WAITING FOR THIS LOCK`**：表示事务正在等待获取某个锁。 - **`HOLDS THE LOCK(S)`**：表示事务当前持有的锁。 **示例分析**（简化日志）： ``` *** (1) TRANSACTION: TRANSACTION 12345, ACTIVE 0 sec inserting LOCK WAIT 2 lock struct(s) RECORD LOCKS ... index PRIMARY ... lock_mode X locks rec but not gap waiting // 等待主键X锁 *** (1) WAITING FOR THIS LOCK: RECORD LOCKS ... index PRIMARY ... lock_mode X locks rec but not gap *** (2) TRANSACTION: TRANSACTION 12346, ACTIVE 0 sec updating HOLDS THE LOCK(S): RECORD LOCKS ... index PRIMARY ... lock_mode X locks rec but not gap // 持有主键X锁 WAITING FOR THIS LOCK: RECORD LOCKS ... index idx_user_id ... lock_mode X // 等待二级索引X锁 ``` **解读**： 1. 事务1（12345）正在等待主键索引上的排他记录锁（`lock_mode X locks rec but not gap`）。 2. 事务2（12346）持有该主键锁，但同时等待二级索引`idx_user_id`上的排他锁。 3. **死锁原因**：事务2持有事务1需要的锁，而事务1可能持有事务2需要的其他锁（日志未完整展示时需结合其他部分）[^3]。 ### 3. **定位冲突操作** - **步骤1：确认锁竞争的资源** 对比两个事务的`RECORD LOCKS`信息，找到相同的`space id`、`page no`、`index`和记录（如主键值）。 - **步骤2：还原SQL执行顺序** 根据事务的SQL语句（日志末尾会打印）和锁等待关系，推断死锁场景： ```sql -- 事务1执行： INSERT INTO t1 (id, name) VALUES (10, 'Alice'); -- 尝试获取id=10的X锁 -- 事务2执行： UPDATE t1 SET name = 'Bob' WHERE id = 10; -- 持有id=10的X锁，同时需要更新其他索引 ``` 若事务2更新时还需锁定二级索引，而事务1的插入恰好阻塞了对二级索引的操作，则形成死锁[^4]。 ### 4. **解决方案** - **调整索引**：确保所有写操作都使用索引查询，避免全表扫描升级为表锁。 - **统一操作顺序**：所有事务按相同顺序访问表和行（如先按主键排序再更新）。 - **减少事务粒度**：将长事务拆分为短操作，及时提交。 ### 示例：死锁日志完整分析流程 假设日志如下： ``` ------------------------ LATEST DETECTED DEADLOCK ------------------------ *** (1) TRANSACTION: TRANSACTION 12345, ACTIVE 0 sec inserting mysql tables in use 1, locked 1 LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s) MySQL thread id 1001, OS thread handle 0x7f8a5c0b6700, query id 2001 localhost root update INSERT INTO orders (order_id, user_id) VALUES (100, 200) *** (1) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 10 page no 5 n bits 72 index `PRIMARY` of table `db`.`orders` trx id 12345 lock_mode X locks rec but not gap waiting *** (2) TRANSACTION: TRANSACTION 12346, ACTIVE 0 sec updating mysql tables in use 1, locked 1 3 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 1 MySQL thread id 1002, OS thread handle 0x7f8a5c0b6800, query id 2002 localhost root update UPDATE orders SET amount=100 WHERE user_id=200 *** (2) HOLDS THE LOCK(S): RECORD LOCKS space id 10 page no 5 n bits 72 index `PRIMARY` of table `db`.`orders` trx id 12346 lock_mode X locks rec but not gap *** (2) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 10 page no 7 n bits 80 index `idx_user_id` of table `db`.`orders` trx id 12346 lock_mode X waiting ``` **分析**： 1. **事务1**：插入新订单（`order_id=100`），需要获取主键100的X锁，但被阻塞（`WAITING`）。 2. **事务2**：更新`user_id=200`的订单，持有某条记录的主键X锁（`HOLDS THE LOCK`），同时需要获取`idx_user_id`索引上的X锁（`WAITING`）。 3. **死锁链**： - 事务2持有主键X锁（假设是主键200），但需要锁`idx_user_id`索引。 - 事务1的插入操作可能涉及`idx_user_id`索引（因`user_id=200`），先获取了该索引的锁，进而阻塞事务2。 - 同时事务1需要主键100的锁（可能被事务2间接阻塞）。 4. **根本原因**：两个事务对主键索引和二级索引的加锁顺序不一致。 **优化方案**： - 为`user_id`添加索引（若已存在则检查是否有效）。 - 代码中保证对`orders`表的操作先按主键排序再执行。 > **提示**：实际分析需结合表结构和SQL语句[^1][^3]。 --- ### 相关问题 1. 如何通过`EXPLAIN`命令分析SQL语句是否会引发全表扫描？ 2. 间隙锁（Gap Lock）在死锁日志中如何表示？ 3. 除了调整索引，还有哪些方法可以避免死锁？ 4. 如何监控MySQL中的死锁发生频率？</think>### 解读MySQL死锁日志中的RECORD LOCKS信息 在MySQL死锁日志中，`RECORD LOCKS`部分揭示了事务持有的锁类型、锁定位置和锁模式，是分析死锁原因的核心。以下是关键信息的解读方法： --- #### 1. **基础结构解析** ```log RECORD LOCKS space id 0 page no 46 n bits 72 index PRIMARY of table `test`.`t1` trx id 246047 lock_mode X locks rec but not gap ``` - **`space id 0`**：表空间ID（0表示系统表空间） - **`page no 46`**：数据页编号（定位锁的物理位置） - **`n bits 72`**：锁位图中的位数（管理锁的位图大小） - **`index PRIMARY`**：锁所在的索引（`PRIMARY`表示主键索引） - **`table test.t1`**：锁涉及的表（`test`库的`t1`表） - **`trx id 246047`**：持有锁的事务ID - **`lock_mode X`**：锁模式（`X`=排他锁，`S`=共享锁） - **`locks rec but not gap`**：锁范围类型（见下表）[^1][^2] --- #### 2. **锁范围类型详解** | **锁类型** | **日志标识** | **作用范围** | **典型场景** | |--------------------------|----------------------------|---------------------------------------|----------------------------------| | **记录锁** | `locks rec but not gap` | 仅锁定单行记录 | `SELECT ... FOR UPDATE`精确匹配 | | **间隙锁** | `locks gap before rec` | 锁定记录前的区间（不包含记录本身） | 范围查询`WHERE id > 100` | | **临键锁**（Next-Key） | `locks gap and rec` | 锁定记录+前间隙（默认锁） | 事务隔离级别`REPEATABLE READ` | --- #### 3. **死锁分析四步法** 1. **定位冲突资源** 对比两个事务的`RECORD LOCKS`，找到相同的`space id` + `page no` + `index`组合 *示例：两个事务都在`page no 46`上等待锁* 2. **分析锁等待链** - `HOLDS THE LOCK(S)`：事务当前持有的锁 - `WAITING FOR THIS LOCK`：事务阻塞等待的锁 ```log TRANSACTION 1: HOLDS LOCK -> index PRIMARY (page 46) // 持有主键锁 WAITING -> index idx_user_id (page 50) // 等待二级索引锁 TRANSACTION 2: HOLDS LOCK -> index idx_user_id (page 50) // 持有二级索引锁 WAITING -> index PRIMARY (page 46) // 等待主键锁 ``` *死锁原因：事务1和2形成资源循环等待*[^3] 3. **结合SQL还原场景** 检查日志末尾导致死锁的SQL： ```sql -- 事务1执行： UPDATE orders SET amount=100 WHERE id=10; -- 持有主键锁，需要更新二级索引 -- 事务2执行： UPDATE orders SET status=1 WHERE user_id=5; -- 持有user_id索引锁，需要更新主键 ``` 4. **验证锁模式冲突** - 排他锁（`X`）与任何锁互斥 - 共享锁（`S`）仅与`X`锁互斥 *若事务1持有`X`锁，事务2尝试获取同行的`X/S`锁都会阻塞* --- #### 4. **典型案例解析 **案例：并发插入导致死锁** ```log -- 事务1日志: RECORD LOCKS ... index PRIMARY ... lock_mode X locks gap before rec insert intention waiting -- 事务2日志: RECORD LOCKS ... index PRIMARY ... lock_mode X locks gap before rec ``` **原因分析**： 1. 事务1尝试在间隙中插入数据（`insert intention`） 2. 事务2持有同一间隙的间隙锁（`gap lock`） 3. 间隙锁与插入意向锁冲突导致死锁 **解决方案**： - 降低隔离级别为`READ COMMITTED`（禁用间隙锁） - 或使用唯一索引避免间隙锁[^2] --- ### 优化建议 1. **索引优化** 为所有WHERE条件列添加索引，避免全表扫描升级为表锁 ```sql ALTER TABLE t1 ADD INDEX idx_user_id(user_id); ``` 2. **事务拆分** 将大事务拆分为小操作，减少锁持有时间 ```java // 错误做法（长事务） @Transactional void processOrder() { updateInventory(); // 耗时操作 insertPayment(); // 持有锁时间过长 } ``` 3. **锁检测重试** ```java try { executeTransaction(); } catch (MySQLTransactionRollbackException e) { if (e.getErrorCode() == 1213) { // 死锁错误码 Thread.sleep(50); retry(); // 指数退避重试 } } ``` > **关键提示**：完整分析需结合`SHOW ENGINE INNODB STATUS`输出的`LATEST DETECTED DEADLOCK`部分[^1][^3]。 --- ### 相关问题 1. 如何通过`EXPLAIN`命令分析SQL语句的潜在锁行为？ 2. 间隙锁（Gap Lock）在哪些场景下会导致死锁？如何避免？ 3. 除了重试机制，还有哪些分布式事务方案可解决MySQL死锁问题？ 4. 如何监控MySQL中的死锁发生频率和影响范围？
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值