mysql单记录也能造成的死锁

在MySQL InnoDB引擎下,即使操作单条记录也可能导致死锁。文章通过一个实例展示了如何在主键和非主键索引操作中产生死锁,解释了InnoDB行级锁实际上是锁定索引而非直接锁定记录,从而导致了这种现象。

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

最近在开发的时候,在mysql Innodb 引擎下,一条记录记录也能引起锁的事件。

场景描述

在项目压测的是,突然发现有类似以下的异常发生:

com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction  
        at sun.reflect.GeneratedConstructorAccessor247.newInstance(Unknown Source)  
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)  
        at java.lang.reflect.Constructor.newInstance(Constructor.java:513)  
        at com.mysql.jdbc.Util.handleNewInstance(Util.java:406)  
        at com.mysql.jdbc.Util.getInstance(Util.java:381)  
        at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1045)  
        at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956)  
        at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3491)  
        at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3423)  
        at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1936)  
        at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2060)  
        at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2542)  
        at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1734)  
        at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2019)  
        at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:1937)  
        at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:1922)  

但代码里面明明只锁了一条记录,不存在多个资源的时候,死锁又是怎么来的呢。

例子

首先创建实验数据:

DROP TABLE IF EXISTS `account_info`;
CREATE TABLE `account_info` (
  `uid` int(11) NOT NULL AUTO_INCREMENT,
  `account` varchar(255) COLLATE utf8mb4_bin DEFAULT NULL,
  `current_amt` decimal(18,2) DEFAULT NULL,
  PRIMARY KEY (`uid`),
  UNIQUE KEY `idx_account` (`account`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;

INSERT INTO `account_info` VALUES (1, 'tester', 1.00);

这里的是 uid 是主键, account 是唯一索引。

时间Transaction1Transaction2
T1set autocommit=false;
begin;
T2select * from account_info where uid = 1 for update;
T3set autocommit=false;
begin;
T4update account_info set current_amt = current_amt +1 where account = ‘tester’;
T5update account_info set current_amt = current_amt +1 where account = ‘tester’;

在执行到T5的时候,mysql 返回了以下的异常:

1213 - Deadlock found when trying to get lock; try restarting transaction, Time: 0.000000s

What? 死锁? 锁一条记录也会死锁?

原理分析

在 mysql 的 innodb 引擎下,行级锁并不是直接锁记录,而是锁索引,如果一条 sql 语句用到了主键索引,mysql 会锁住主键索引;如果一条语句操作了非主键索引,mysql 会先锁住该非主键索引,再锁住主键索引。

例子

  • 新开一个session,执行以下语句
set autocommit=false;
begin;
select * from account_info where uid = 1 for update;
  • 然后再打开另外一个session,执行查看 innodb 事务
select * from information_schema.INNODB_TRX;

会出现以下内容摘要,其中 trx_rows_locked 内容是 1

trx_idtrx_statetrx_tables_lockedtrx_rows_lockedtrx_rows_modifiedtrx_isolation_level
5831745RUNNING110REPEATABLE READ
  • 把前面的 session 关闭后,再重新打开一个session执行以下语句
set autocommit=false;
begin;
select * from account_info where account = 'tester' for update;
  • 然后再打开另外一个session,执行查看 innodb 事务
select * from information_schema.INNODB_TRX;

会出以下内容摘要,其中 trx_rows_locked 内容是 2

trx_idtrx_statetrx_tables_lockedtrx_rows_lockedtrx_rows_modifiedtrx_isolation_level
5831748RUNNING120REPEATABLE READ

会看到上面的例子,用主键索引加锁的时候,只会出现一把锁,若用非主键索引的时候,就出现了两把锁,这也是单条记录造成了死锁的原因。

在这里插入图片描述

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值