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

Posted 2021-05-01 码农Coco

    问题:

    苏宁的一个朋友在群里发了这样的一个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.再更新记录。

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

1. select id from x_table where id=? 

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