mysql死锁案例及解决方案_Mysql死锁案例分析解决方案及知识整理

问题:

苏宁的一个朋友在群里发了这样的一个BUG

配置及问题分析:

select @@tx_isolation查看隔离级别,补充一下,mysql默认的隔离级别为repeatable-read

sql分析:

mysql. 并发delete同一行记录,偶发死锁.

delete from x_table where id=?

死锁分析:

mysql的事务支持与存储引擎有关,MyISAM不支持事务,INNODB支持事务,更新时采用的是行级锁。这里采用的是INNODB做存储引擎,意味着会将update语句做为一个事务来处理。前面提到行级锁必须建立在索引的基础,这条更新语句用到了索引idx_1,所以这里肯定会加上行级锁。

行级锁并不是直接锁记录,而是锁索引,如果一条SQL语句用到了主键索引,mysql会锁住主键索引;如果一条语句操作了非主键索引,mysql会先锁住非主键索引,再锁定主键索引。

这个update语句会执行以下步骤:

1、由于用到了非主键索引,首先需要获取idx_1上的行级锁

2、紧接着根据主键进行更新,所以需要获取主键上的行级锁;

3、更新完毕后,提交,并释放所有锁。

如果在步骤1和2之间突然插入一条语句:update user_item .....where id=? and user_id=?,这条语句会先锁住主键索引,然后锁住idx_1。

蛋疼的情况出现了,一条语句获取了idx_1上的锁,等待主键索引上的锁;另一条语句获取了主键上的锁,等待idx_1上的锁,这样就出现了死锁。

解决方案:

1.先获取需要更新的记录的主键

2.再更新记录。

也就是代码中的应该这样写:

select id from x_table where id=?

delete from x_table where id=?

问题总结:

在采用INNODB的MySQL中,更新操作默认会加行级锁,行级锁是基于索引的,在分析死锁之前需要查询一下mysql的执行计划,看看是否用到了索引,用到了哪个索引,对于没有用索引的操作会采用表级锁。如果操作用到了主键索引会先在主键索引上加锁,然后在其他索引上加锁,否则加锁顺序相反。在并发度高的应用中,批量更新一定要带上记录的主键,优先获取主键上的锁,这样可以减少死锁的发生。

小结:

这个问题是群里的另外一个朋友解决的,看了他的分析的之后收获良多,原文链接在后面有贴上。之前在看《阿里巴巴java开发手册》的时候,记得里面有一条,代码中的sql有个职能单一原则,当时没看明白(感觉手册也没写很明白),现在明白过来了,sql职能单一不仅仅是方便代码阅读与维护,还涉及到数据库表锁以及事务的的一系列问题,在并发场景下会出现各种问题,复杂sql在并发场景会出现死锁问题或者隔离级别的问题。

另外要明白这个问题,推荐两篇文章:

1 关于事务隔离级别的

https://segmentfault.com/a/1190000008677275

2 关于mysql基础的,感觉这篇帖子索引讲的特别细腻

https://notes.diguage.com/mysql/#_索引类型

你可能感兴趣的:(mysql死锁案例及解决方案)