MySQL InnoDB（Spring）并发事务导致的死锁及解决方案

矫情吗；* 2022-04-01 16:53 574阅读 0赞

**解决方案在最下面，欢迎指导、吐槽和建议**

前提：`InnoDB`存储引擎 + 默认的事务隔离级别 `Repeatable Read`  
用`MySQL`客户端模拟并发事务操作数据时，如下表按照时间的先后顺序执行命令，会导致死锁。  
数据库数据如下，id为主键。

select * from a ;
    +----+
    | id |
    +----+
    |  3 |
    +----+
    |  8 |
    +----+
    |  11 |
    +----+

<table> 
 <thead> 
  <tr> 
   <th>时间</th> 
   <th>会话A</th> 
   <th>会话B</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>1</td> 
   <td>begin;</td> 
   <td></td> 
  </tr> 
  <tr> 
   <td>2</td> 
   <td>delete from a where id = 4;</td> 
   <td></td> 
  </tr> 
  <tr> 
   <td>3</td> 
   <td></td> 
   <td>begin;</td> 
  </tr> 
  <tr> 
   <td>4</td> 
   <td></td> 
   <td>delete from a where id = 6;</td> 
  </tr> 
  <tr> 
   <td>5</td> 
   <td>insert into a values(5);</td> 
   <td></td> 
  </tr> 
  <tr> 
   <td>6</td> 
   <td></td> 
   <td>insert into a values(7);</td> 
  </tr> 
  <tr> 
   <td>7</td> 
   <td>Query OK, 1 row affected</td> 
   <td></td> 
  </tr> 
  <tr> 
   <td>8</td> 
   <td></td> 
   <td>ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction</td> 
  </tr> 
  <tr> 
   <td>9</td> 
   <td>commit;</td> 
   <td></td> 
  </tr> 
 </tbody> 
</table>

**为什么看似互不影响的事务会出现死锁的问题？**

我们一定听说过`MySQL`中存在共享锁(`S`锁)和排他锁(`X`锁)，可能听说过有意向共享锁(`IS`锁)和意向排他锁(`IX`锁)，上面出现死锁的情况，一定是存在这几种锁的相互等待。

**`InnoDB`存储引擎实现共享锁（`S Lock`）和排它锁（`X Lock`）两种行级锁，注意：行锁！行锁！行锁！**  
`S Lock`：允许事务读**一行**数据，多个事务可以并发的对行数据加`S Lock`  
`X Lock`：允许事务删除或更新**一行**数据，只有行数据没有任何锁才可以获取`X Lock`

**`InnoDB`支持意向共享锁（`IS Lock`）和意向排它锁（`IX Lock`），这两种锁是表级别的锁，但实际上也应用在行锁之中**  
`IS Lock`：事务想要获得一张表中**某几行**的共享锁  
`IX Lock`：事务想要获得一张表中**某几行**的排它锁

**锁的分类：**

*  **行锁**  
    锁定一行数据，即上面所说的共享锁和排他锁
 *  **间隙锁**  
    锁定一个范围，但不包含记录本身。例如数据库中数据`id`为3，8，11，那么锁定的区间可能为（-∞,3），(3,8)(8,11)，(11,+∞)，假如插入的数据为6，那此时锁定的区间为(3,6)，(6,8)被锁定，不包括要插入的6.
 *  **行锁 + 间隙锁**  
    锁定一个范围，包括记录本身，例如数据库中数据`id`为3，8，11，那么锁定的区间可能为（-∞,3\]，(3,8\](8,11\]，(11,+∞\]，假如插入的数据为6，此时锁定的区间(3,8\]变为(3,6\]，(6,8\]两个部分，可以看到，6也被锁定。

**为什么要有间隙锁？**

我们应该听说过幻读，即在同一事务下，连续执行两次同样的`SQL`语句可能导致不同的结果，第二次的`SQL`语句可能返回之前不存在的行。`InnoDB`使用行锁 + 间隙锁的方式解决这个问题。当然，`InnoDB`存储引擎在查询数据时是不存在锁的，这是因为查询的数据来自于快照版本，即历史数据。

**锁的应用：**

*  **insert 插入记录时，需要获取行锁**
 *  **update 更新一条记录时，如果记录存在，需要行锁；如果记录不存在，行锁 + 间隙锁**
 *  **delete 删除一条记录时，如果记录存在，需要行锁；如果记录不存在，行锁 + 间隙锁**
 *  **select 查询记录时，不会存在锁，除非显示的调用lock in share mode或者for update，如下所示。为什么查询不存在锁呢？因为InnoDB引擎select查询返回的是数据的快照版本，这也是为什么在许多mysql书中，事务的select查询需要锁时，要显示的使用加锁语法。参见[MySQL查询不需要锁][MySQL]，了解更多有关InnoDB查询的机制。**
    
        # S Lock
        select * from a where id = 1 lock in share mode ;
        # X Lock
        select * from a where id = 1 for update ;

掌握了这些知识的话，我们再来看上面两个事务为什么会出现死锁的问题。上面说列id是主键，实际上只要是索引，不论是唯一索引、组合索引、普通索引，都会存在间隙锁的问题。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMwMDM4MTEx_size_16_color_FFFFFF_t_70]

**上面发生死锁的情况是当数据不存在时，当数据存在时，也会出现死锁的情况，这种情况可以通过3个会话来模拟，当然在实际的项目情况下，并发事务确实是带来了死锁的问题，例如在Spring事务中，先删除表A中的数据，再向表A插入数据，如果并发量比较大的话，如果存在间隙锁，那么有几率会出现死锁的问题。  
Spring事务中大致的运行流程如下：**  
**一个事务中存在先删除再插入的逻辑，并发时，事务A将存在的数据id=6删除，此时事务B也删除id=6的数据，事务C同样删除id=6的数据，这种情况下，如果并发量够大，一定会出现间隙锁，从而发生死锁。**

**解决方法：**  
方法一：通常情况下，要删除一条数据，先查询数据是否存在，如果存在，再根据主键（最好非联合主键）删除，否则不执行删除逻辑。其实这种方式也存在一定的风险，我们可以通过软删除的方式，避免高并发时出现数据已被删除，而其他事务正在删除不存在的数据。软删除是指通过字段决定数据是否已删除，然后定时的手动处理数据库中的数据。  
方法二：使用队列，通过手动处理数据关键字做`hash`，把一类数据路由到相同的队列，队列会按串行的方式处理数据，但是这种方式只能保证一个服务节点是正常的，如果高可用下多个服务节点同时处理数据，仍然有几率出现这样的问题。此时可以通过外部调整，使一类数据只请求同一个服务节点。这种方法适用于对数据完整性不做要求的情况，因为服务宕机会导致内存数据丢失。这种方式我实现过一套。  
方法三：使用高可用消息中间件处理数据，类似于方法二。但这种方式不会因为服务宕机导致数据丢失，并且消息中间件如`MQ`都会有保证数据最终一致性的策略。  
方法四：尽量避免间隙锁的存在，参见[MySQL常见死锁及解决方案][MySQL 1]。  
方法五：其他方式，我还没有了解到，如果您知道方法，请给我留言，我会做进一步的验证。

[MySQL]: https://blog.csdn.net/qq_30038111/article/details/86255156
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMwMDM4MTEx_size_16_color_FFFFFF_t_70]: /images/20220401/04803f0b3fbe48ac8fd602ada2acc9f3.png
[MySQL 1]: https://blog.csdn.net/qq_30038111/article/details/95165961