MySQL 中的 INSERT 是怎么加锁的？

最新推荐文章于 2023-12-23 21:15:00 发布

Java云海.

最新推荐文章于 2023-12-23 21:15:00 发布

阅读量235

点赞数

文章标签： mysql java 面试

本文链接：https://blog.csdn.net/a1472750149/article/details/121252035

版权

本文探讨了MySQL中INSERT语句的加锁过程，解答了一个关于幻读的疑问。在RR隔离级别下，分析了INSERT如何避免幻读，以及在插入前后的加锁行为。通过分析源码，揭示了INSERT在插入数据时不加锁，而是通过隐式锁转换为显式锁的过程，从而确保无幻读现象。文章还提到了MySQL源码编译和调试的步骤，以及对InnoDB引擎中Latch的概念进行了介绍。

摘要由CSDN通过智能技术生成

在之前的博客中，我写了一系列的文章，比较系统的学习了 MySQL 的事务、隔离级别、加锁流程以及死锁，我自认为对常见 SQL 语句的加锁原理已经掌握的足够了，但看到热心网友在评论中提出的一个问题，我还是彻底被问蒙了。

他的问题是这样的：

加了插入意向锁后，插入数据之前，此时执行了 select...lock in share mode 语句（没有取到待插入的值），然后插入了数据，下一次再执行 select...lock in share mode（不会跟插入意向锁冲突），发现多了一条数据，于是又产生了幻读。会出现这种情况吗？

这个问题初看上去很简单，在 RR 隔离级别下，假设要插入的记录不存在，如果先执行 select...lock in share mode 语句，很显然会在记录间隙之间加上 GAP 锁，而 insert 语句首先会对记录加插入意向锁，插入意向锁和 GAP 锁冲突，所以不存在幻读；如果先执行 insert 语句后执行 select...lock in share mode 语句，由于 insert 语句在插入记录之后，会对记录加 X 锁，它会阻止 select...lock in share mode 对记录加 S 锁，所以也不存在幻读。两种情况如下所示：

先执行 INSERT 后执行 SELECT：

先执行 SELECT 后执行 INSERT：

但是我们仔细想一想就会发现哪里有点不对劲，我们知道 insert 语句会先在插入间隙上加上插入意向锁，然后开始写数据，写完数据之后再对记录加上 X 记录锁。

那么问题就来了，如果在 insert 语句加插入意向锁之后，写数据之前，执行了 select...lock in share mode 语句，这个时候 GAP 锁和插入意向锁是不冲突的，查询出来的记录数为 0，然后 insert 语句写数据，加 X 记录锁，因为记录锁和 GAP 锁也是不冲突的，所以 insert 成功插入了一条数据，这个时候如果事务提交，select...lock in share mode 语句再次执行查询出来的记录数就是 1，岂不是就出现了幻读？

最新面试题整理好了，点击Java面试库小程序在线刷题。

整个流程如下所示（我们把 insert 语句的执行分成两个阶段，INSERT 1 加插入意向锁，还没写数据，INSERT 2 写数据，加记录锁）：

一、INSERT 加锁的困惑

在得出上面的结论时，我也感到很惊讶。按理是不可能出现这种情况的，只可能是我对这两个语句的加锁过程还没有想明白。

于是我又去复习了一遍 MySQL 官方文档，Locks Set by Different SQL Statements in InnoDB 这篇文档对各个语句的加锁有详细的描述，其中对 insert 的加锁过程是这样说的（这应该是网络上介绍 MySQL 加锁机制被引用最多的文档，估计也是被误解最多的文档）：

INSERT sets an exclusive lock on the inserted row. This lock is an index-record lock, not a next-key lock (that is, there is no gap lock) and does not prevent other sessions from inserting into the gap before the inserted row.