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/#_索引类型