笔者最近在生产环境错误日志上看到updating database. Cause: com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction 这样的日志 ,网上看了很多文章 发现这篇文章 跟自己的场景非常接近。也没像作者翻binlog日志
但综合分析我的情况应该是相同表记录行锁冲突
在我一次执行三个update table1 ,table2 set table.xx=table2.xx where ..
update table1,table2 set table1.yy=table2.yy where ...
update table1,table2 set table1.xx=table2.xx where ...
update table1,table2 set table1.zz=table2.zz where ...
而且我的where 条件列是没有建立索引 所以锁住的是整表。
事务一直执行过程中 锁住记录后没有释放 事务2执行时 遇到相同记录 等待事务1 事务三 又等待事务二 因为有相同行数涉及 ,这个时候 事务1执行完毕 等待事务3 就造成死锁现象
当事务1执行语句1时 锁住了某几行 这时事务2执行的时候 也需要更新相同的几行 但发现那几行被事务1锁住
上图是我接收到的错误报警,SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction,错误信息显示我们业务中有一条数据库操作遇到了死锁情况。接下来就开始我们的追查之旅。
1.执行“show engine innodb status”获取INNODB引擎当前信息(show engine innodb status 详细介绍)
LATEST DETECTED DEADLOCK记录了最近一次的死锁情况。
2017-01-04 09:25:17时间跟我们接收到的报错日志时间吻合。
上面还可以看出两个事务之间发生锁竞争时,给我们留下的部分数据
事务1
UPDATEskuSETquantity=quantity-'1',lock_stock=lock_stock+'1',sys_version=sys_version+1 WHEREid= '15608' ANDquantity>= '1' limit 1
事务2
UPDATEskuSETquantity=quantity-'1',lock_stock=lock_stock+'1',sys_version=sys_version+1 WHEREid= '15504' ANDquantity>= '1' limit 1
死锁的两个资源均被lock_mode X locks了
最后,mysql给了很重要的一个数据“WE ROLL BACK TRANSACTION (2)” MYSQL回滚了事务2。既然mysql回滚了事务2,那么肯定是事务2的语句触发了死锁,被mysql回滚了,也就是应该为报错日志所记录的那部分。同时,MYSQL执行了事务1,那么事务1的SQL语句肯定被记录在BINLOG中了。
2.查看binlog日志,找出事务1所执行的语句
查找依据:
SQL语句,根据LATEST DETECTED DEADLOCK提供的死锁时记录的sql语句。
线程ID(mysql的唯一标识): MySQL thread id 11572504
执行时间(时间线):2017-01-04 09:25:17 7f553477d700
根据以上三个标识,以及BINLOG的起始标志“BEGIN、COMMIT”,几乎可以100%确定事务1所包含的SQL语句。
binlog信息大致如下
3.还原事务2所包含的执行语句
事务1的语句找齐了,接下来找事务2的语句,还记得我们开头提供的报错日志吗,那个日志里也详细记录了发起请求时的参数情况(截图未展示),根据参数和我们处理业务的代码,可以复现事务2所要执行的语句
根据两个事务所执行的sql语句,目前可以还原死锁产生的原因了
4.查看两个事务执行语句的顺序:
顺序事务1事务2说明
1
begin
2
begin
3
UPDATE sku
SET quantity=quantity-'1',
lock_stock=lock_stock+'1',
sys_version=sys_version+1
WHERE id = '15504' AND
quantity >= '1' limit 1
事务1 给 sku表 id 15504记录上 X 锁
4
UPDATE sku
SET quantity=quantity-'1',
lock_stock=lock_stock+'1',
sys_version=sys_version+1
WHERE id = '15608' AND
quantity >= '1' limit 1
事务2 给 sku表 id 15608记录上 X 锁
5
UPDATE sku
SET quantity=quantity-'1',
lock_stock=lock_stock+'1',
sys_version=sys_version+1 WHERE id = '15608' AND
quantity >= '1' limit 1
这里是关键,事务1想给sku表 id 15608上X锁,发现被别人(事务2)上锁了,等待锁释放
6
UPDATE sku
SET quantity=quantity-'1',
lock_stock=lock_stock+'1',
sys_version=sys_version+1
WHERE id = '15504' AND
quantity >= '1' limit 1
事物2打算给sku表id为15504记录上 X 排它锁,发现被其他事务上了,而且此事务居然还在等他提交,这时MYSQL立刻回滚事务2…(php发现MYSQL返回死锁信息,记录该信息到错误日志…发送回滚指令…mysql已经“帮”他回滚了…)
7
执行成功
事务1发现别人的锁释放了,获得X锁,执行成功
8
commit
事务1执行成功,记录binlog日志
解决方案
减小事务中的语句数量
在业务中调整语句的执行顺序,例如可以按照where条件中字段的大小进行一下排序,按照排序后顺序执行,让死锁变为锁等待。
相关补充
innodb的行锁,锁的是查询条件中的索引字段,以及索引字段对应的primary key字段