MySQL 5.5 版本,事物中因为 S 锁,导致后续 update 语句出现死锁,请大佬帮我分析一下

场景:有一个提交订单的操作,在事物执行过程中库存表被操作两次,第一次是 select 语句,第二次是 update,在执行过程中出现了死锁。#

事物中包含这个表的操作的两处代码如下:

第一处#

MySQL 5.5 版本,事物中因为 S 锁,导致后续 update 语句出现死锁,请大佬帮我分析一下

第二处#

MYSQL 5.5版本,事物中因为S锁,导致后续update语句出现死锁,请大佬帮我分析一下
两处代码中有一些判断库存是否足够的逻辑

在并发中出现了死锁的情况,死锁日志附在最后。
因为死锁日志中说有一个事物拥有 S 锁,但是我并没有在事物的任何地方用 lock in share mode 加锁,有点想不通,google 上也没有找到有价值的资料,我所了解到的 select 除非显示指定加锁,否则不会任何锁到查询结果上,那么这个 S 锁是怎么来的呢?

附录:

  1. show engine InnoDB status 的结果

    代码已被折叠,点此展开
讨论数量: 3
LearnKuJ

select for update 就是在拿锁,把 for update 去掉就不会死锁了。

5年前 评论
liuwq (楼主) 5年前
liuwq (楼主) 5年前

有没有可能你 select 语句是表锁,导致 update 等待?

4年前 评论

这个问题我后来没有再深究,给加了一个文件锁,不同进程到这里排队就行了,本来就是异步任务,感觉研究并发问题没有必要,哈哈

4年前 评论