MySQL 与InnoDB 下的锁做朋友（三）行锁/记录锁

港控/mmm° 2023-01-19 13:52 10阅读 0赞

# **前言** #

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1Mzg3OTQw_size_16_color_FFFFFF_t_70][]

# **正文**     #

今天我们将要认识这位朋友是 行锁，而这个行锁 我想叫他 行记录锁。

他和另外两位朋友，临键值锁、间隙锁 ，都是 行锁的实现方式。

还记得咱们一开始在了解innodb引擎下的行锁，强调了好几次，**行锁是建立在索引上的**。

行记录锁当然也是了， 他是建立在当行记录上的 排他锁。

开始实战演示：

表数据准备：  
user表（id主键索引，其余无索引）：  
![20210527162005675.png][]

1. 模拟A事务 查询 id =1 的数据（注意使用for update 触发行锁），故意查询完不提交事务:

![20210527162506909.png][]

2.模拟B事务，也查询id=1的数据 ：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1Mzg3OTQw_size_16_color_FFFFFF_t_70 1][]

此时，发现无法查询出数据，因为id=1这行数据， 已经上了行记录锁 ，所以我们可以查看确实存在一个事务在等待锁资源：  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1Mzg3OTQw_size_16_color_FFFFFF_t_70 2][]

如果我们一直让A事务不提交事务，也就是不释放锁资源，那么B事务就会一直等待，直到超时：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1Mzg3OTQw_size_16_color_FFFFFF_t_70 3][]

同样，A事务依然不提交，此时执行C事务来更新id=1的行数据,同样也是处于等待锁资源状态：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1Mzg3OTQw_size_16_color_FFFFFF_t_70 4][]

以上情况都是属于，排他锁之间的写写互斥(行记录锁 record锁属于排他锁一种实现方式)。

那么依然 A事务不提交事务，还坚持不释放锁资源， 执行事务D 查询id=1的数据（使用共享读锁S ）:  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1Mzg3OTQw_size_16_color_FFFFFF_t_70 5][]

可以看到依然是处于等待锁资源状态，因为 排他锁一旦上了，是写读互斥的。

我们在这个系列里的（二）讲过跟排他锁相关的知识，如果还不清楚，可以移步   
MySQL 与InnoDB 下的锁做朋友 （二）共享锁与排他锁  
[https://blog.csdn.net/qq\_35387940/article/details/115185746][https_blog.csdn.net_qq_35387940_article_details_115185746]

PS：

<table> 
 <tbody> 
  <tr> 
   <td></td> 
   <td><strong>共享锁（共享读锁）</strong></td> 
   <td><strong>排他锁（独占写锁）</strong></td> 
  </tr> 
  <tr> 
   <td>共享锁（共享读锁）</td> 
   <td>可以，兼容，一起读</td> 
   <td>不可以，不兼容，想写得等共享锁没了</td> 
  </tr> 
  <tr> 
   <td>排他锁（独占写锁）</td> 
   <td>不可以，不兼容，上了排他锁，别人啥都不能动</td> 
   <td>不可以，不兼容，上了排他锁，别人啥都不能动</td> 
  </tr> 
 </tbody> 
</table>

行锁简单就介绍到这把。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1Mzg3OTQw_size_16_color_FFFFFF_t_70]: /images/20221021/d1f73e894c184583b93c518176857d97.png
[20210527162005675.png]: /images/20221021/4ddb652576644b67b31776744d6135d7.png
[20210527162506909.png]: /images/20221021/38d16e9c13134c5baf676d0036984fa5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1Mzg3OTQw_size_16_color_FFFFFF_t_70 1]: /images/20221021/7d4233edd0744e8eaefd7728ade68d23.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1Mzg3OTQw_size_16_color_FFFFFF_t_70 2]: /images/20221021/4c92ca53f74a4efa9ba770c6d543a369.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1Mzg3OTQw_size_16_color_FFFFFF_t_70 3]: /images/20221021/ba9f9ed8cd374dd380af143779aa7177.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1Mzg3OTQw_size_16_color_FFFFFF_t_70 4]: /images/20221021/b76ff9f282574ae29f689ba80058b11b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1Mzg3OTQw_size_16_color_FFFFFF_t_70 5]: /images/20221021/89507307356e4954a24724337f9df33a.png
[https_blog.csdn.net_qq_35387940_article_details_115185746]: https://blog.csdn.net/qq_35387940/article/details/115185746