事务的隔离性（InnoDB存储引擎的并发控制）

怼烎@ 2023-06-25 02:15 11阅读 0赞

一、四种并发访问问题

一、锁机制

1、锁的概述

InnoDB存储引擎中，事务的隔离性主要是由锁机制实现的。开发多用户的应用，很大的一个难点就在于并发访问：一方面既要最大程度地实现数据库的并发访问，另一方面又要确保每个用户能以一致的方式读取、修改数据，为此，我们需要锁机制。

锁机制是数据库系统区别于文件系统的另一个关键特性，锁机制用于管理对共享资源的并发访问，保证数据的完整性和一致性。这里的共享资源不仅仅是行数据，还包括缓冲池中的LRU列表，删除、添加、移动LRU列表中的元素时，有需要锁来保证一致性。

2、锁的类型

（1）共享/排他锁

MySQL提供了两种锁的粒度：行级锁、表级锁。一般而言，锁的粒度越小，并发度越高；锁用得越多，开销越大（锁的各种操作如获取锁、释放锁、检查锁状态等都会增加系统开销）。因此我们通常只锁定尽可能少的数据量，另外我们需要在锁开销和并发度之间找好平衡点。

InnoDB存储引擎提供两种行级锁：

共享锁（S Lock）：允许事务读一行数据；

排他锁（X Lock）：允许事务删除或更新一行数据。

如果事务T1已经获得行r的共享锁，那么事务T2可以立即获得行r的共享锁以读取数据（锁兼容）；如果事务T1已经获得行r的共享锁/排他锁，那么事务T2要想获得行r的排他锁/共享锁或排他锁必须等待事务T1释放锁（锁不兼容）。共享锁和排他锁均用在事务中，随着事务的结束而释放。

![20191224152130425.png][]

（2）意向锁

InnoDB存储引擎支持意向锁的锁方式以实现**多粒度锁定**功能，所谓的多粒度锁定就是允许事务在行级上的锁和表级上的锁同时存在。意向锁在原来的 X/S 锁之上引入了两种表锁 IX/IS 锁：

意向共享锁（IS Lock），事务有意向获得一张表中某几行的共享锁；

意向排他锁（IX Lock），事务有意向获得一张表中某几行的排他锁

意向锁机制的工作方式：意向锁将锁定的对象分为多个层次（InnoDB存储引擎分为表级、行级两个层次），要想对最下层的对象（最细粒度的对象，行）上锁，需要先对上层对象上锁（粗粒度的对象，表）。也就是说，1）事务要想获得某些行的S锁，必须先获得表的IS锁； 2）事务要想获得某些行的X锁，必须先获得表的IX锁。 而获得各种锁的兼容性如下图所示：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMwOTczNDMx_size_16_color_FFFFFF_t_70][]  
从上图可以看出：意向锁之间始终是兼容的，表级的共享/排他锁之间的兼容性则跟前面行级的共享/排他锁之间的兼容性一样，至于意向锁与表级的共享/排他锁之间则是我们关注的重点，这也是意向锁机制存在的意义。我们可以看到，排他锁是很强的锁，不与其他类型的锁兼容。而修改和删除某一行的时候，必须获得强锁，禁止这一行的其他并发，以保障数据的一致性。

不过问题来了，按理说即时没有意向锁机制，只存在行级锁和表锁，那么在并发修改和删除时，也是可以保证数据的一致性的。比如事务T要给表A加X锁，它会判断此时是否存在其他事务已经获得表A的表锁 或者 已经获得表A的任意一行的锁，如果存在，则事务T阻塞直到可以获得锁。既然如此为什么还要有意向锁呢？

原因在于上面的过程中，当检测是否有其他事务对表A的任意一行已经加了锁的过程中，需要对表A的每一行都检测一次，而这种遍历是非常耗时间的。而在意向锁机制下的话，其他事务要想获得表A任意一行的行级锁，必须先获得表A的意向锁，这样一来，当事务T想给表A加X锁时，就可以马上检测到其他事务已经给表A加上表级锁（X / IX / S / IS锁），X锁与其不兼容，所以事务T被阻塞。因此，意向锁机制是可以提高数据库的并发度的，这大概是InnoDB存储引擎使用意向锁的原因之一吧。

意向锁的实际例子：

select ...  lock in share mode，由于要获得S锁，因此此SQL语句会先获得IS锁；

select ...  for update, 由于要获得X锁，因此此SQL语句会先获得IX锁

3、小结

我们知道事务之所以需要隔离性，是因为多个事务并发修改同一个数据的时候，会产生不一致等问题。而锁机制就是保证事务隔离性的主要手段之一，由于多个事务对同一数据进行并发读不会存在问题，所以前面讨论的锁机制主要用于多个事务对同一数据进行并发读写的场景。由于InnoDB存储引擎提供的多粒度锁定功能，MySQL可以根据不同情况灵活选择锁的粒度，因此，与MyISAM存储引擎相比，InnoDB存储引擎的并发性能是比较强的，这也是MySQL与其他数据库系统相比的优势之一。

二、MVCC机制

1、MVCC概述

上面讨论的通过锁机制进行并发控制，其实还不够好。因为它只是让事务在读读场景下并行，在读写场景、写写场景下尽可能缩小锁的粒度来提高并发度。不过，InnoDB存储引擎还支持MVCC机制，也就是多版本并发控制，它可以提高事务在读写场景下的并发度。

2、一致性非锁定读

3、一致性锁定读

有些情况用户需要显式地对读操作加锁以保证数据逻辑的一致性，加锁方式有两种：

1）select ... for update;

这种加锁方式会对读取的行记录/表加一个X锁，其他事务不能对已被锁定的行/表加上任何锁。注意，在一致性非锁定读的模式下，其他事务还是可以对被这种方式锁定的行进行读取的。

2）select ... lock in share mode;

这种加锁方式会对读取的行记录/表加一个S锁，其他事务可以向已被锁定的行/表加S锁，但不可以加X锁。其实就是前面讨论的锁机制所提供的功能。

4、小结

一致性非锁定读，也称为快照读，可以看成是牺牲数据的实时性，在本事务内读取数据的最新版本或某个历史版本，因此，可以在读写场景中不加读锁，从而不阻塞其他事务加写锁，也不用等待其他事务已加的写锁的释放，这样，事务在读写场景下的并发性能自然就上来了。

一致性锁定读，也称为当前读，其实就是通过加写锁的方式，既保证数据的一致性，又要求读到的数据必须是最新版本的。

二、四种并发访问问题

下面演示一下四种并发访问问题

1、覆盖修改

覆盖修改出现在写写场景下，两个事务同时对同一个数据进行修改，第一个事务先完成修改，第二个事务随后完成修改，第二个事务的修改结果覆盖掉了第一个事务的修改结果。

InnoDB存储引擎不存在覆盖修改的问题，因为锁机制保证了在写写场景下串行进行

create table account (
        id int primary key,
        amount int
    ) engine=innodb;
    
    insert into account value (10001, 100);

设置会话A、会话B的事务隔离级别为读未提交，会话1开启事务A，会话2开启事务B

set session transaction isolation level read uncommitted;

1）首先，事务A更新账户10001的余额，但未提交，事务B在事务A更新语句执行完后，同样执行更新操作。此时由于事务A没有释放对记录的X锁，事务B被阻塞。

事务A：

![20191226125825156.png][]

事务B：

![20191226130448484.png][]

2）其次，事务A执行提交操作，释放X锁，事务B获得X锁，开始执行更新语句

事务A：

![20191226130536416.png][]

事务B：刚刚被阻塞的更新语句在事务A提交后的瞬间开始执行

![20191226130624255.png][]

3）最后，查看余额的值

在没有锁机制的情况下，事务B并不会等待事务A执行完再执行，两者是近乎同时进行。事务A执行的操作是100-10=90，事务B执行的操作是100-20=80，最终结果是80，也就是事务A的修改被事务B的修改覆盖掉。而这里的结果是正确的，是因为锁机制的存在，保证了即使是最弱隔离级别之下，也不会出现覆盖修改的现象。

![20191226130718294.png][]

2、读脏数据

读脏数据发生在读写场景下，事务A修改/插入一条数据，并且事务A未提交，事务B随后读取到事务A的这个更新，则称事务B读到了脏数据。

InnoDB存储引擎的读未提交隔离级别无法避免读脏数据问题

drop table t;
    create table t (
        id int(11) not null,
        c int(11) default null,
        d int(11) default null,
        primary key(id),
        key c(c)
    ) engine=innodb;
    
    insert into t values(0,0,0), (5,5,5), (10,10,10), (15,15,15), (20,20,20), (25,25,25);

设置会话一的事务隔离级别为读未提交

![20191226134911954.png][]

设置会话二的事务隔离级别为任意类型，这里设置为可重复读

![20191226135055366.png][]

按照下面的时间序列执行

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMwOTczNDMx_size_16_color_FFFFFF_t_70 1][]

可见，会话一的事务中看到了会话二的某个事务未提交的修改结果，导致前后的查询结果不一致，这就是读脏数据现象。如果将会话一设置为读提交，则可以避免此问题，如下面所示：

![20191226140200262.png][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMwOTczNDMx_size_16_color_FFFFFF_t_70 2][]

3、不可重复读

不可重复读同样也是发生在读写场景下，事务A修改/插入一条数据，并且事务A已经提交，事务B读到了事务A的这个更新，则称事务B不可重复读。

InnoDB存储引擎的读提交隔离级别无法避免不可重复读问题。

同样使用上面的表的定义和表数据，会话一采用读提交隔离级别，会话二采用可重复读隔离级别

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMwOTczNDMx_size_16_color_FFFFFF_t_70 3][]

会话二开启一个自动提交的事务，在该事务提交前后，会话一的事务读到不一致的结果。将会话一的隔离级别设置为可重复读即可解决此问题，执行结果如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMwOTczNDMx_size_16_color_FFFFFF_t_70 4][]

可以看到在会话一的第一个事务执行过程中，会话二的事务对共享数据的修改，不影响会话一的第一个事务的执行结果（这种机制就是上面讨论的MVCC的当前读机制）。而当会话一重新开启一个事务时，就看到了会话二的更新结果了。

不可重复之意，在于事务B在事务A更新、提交前后，读到的结果是不一致的。注意和读脏数据不一样，读脏数据是事务B在事务A更新、但未提交前后，读到的结果是不一致的。

4、读幻象

读幻象问题也是发生在读写场景下，一个事务在前后两次查询同一个范围的时候，后一次查询看到了前一次查询中没有看到的行

InnoDB存储引擎的读提交隔离级别除了无法避免不可重复读问题，还存在读幻象问题。

还是使用上面的表的定义和表数据，会话一采用读提交隔离级别，会话二采用可重复读隔离级别

![20191226142925864.png][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMwOTczNDMx_size_16_color_FFFFFF_t_70 5][]

上面的执行流程中，select \* from t where d=5 for update;语句执行的功能是，查询所有d=5的行，并且加上写锁（即，使用的是当前读，而不是快照读）。这里所有d=5的行记录构成了一个集合，也就是说，此语句查询的是处于d=5的这个集合范围内的所有记录。这里出现了读幻象的现象，三条语句的执行结果不一致。

原因是查询语句的X锁只锁定了当前满足条件的行记录。第一次执行时，满足d=5的集合为T = \{(5,5,5)\}，集合T里面的所有行记录都被记上了X锁，但此时行记录(0,0,0)不在集合T里面，所以会话二可以对其进行读写。第二次执行时，满足d=5的集合变为T' = \{(0,0,5), (5,5,5)\}，此时会话二可以插入数据(1,1,5)，所以第三次查询时，满足d=5的集合就变为T'' = \{(0,0,5), (1,1,5), (5,5,5)\}了。

通过上面的分析，我们可以看到之所以产生了幻读现象，是因为

将会话一的隔离级别设置为可重复读 / 可序列化，即可解决读幻象问题，执行结果如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMwOTczNDMx_size_16_color_FFFFFF_t_70 6][]

InnoDB存储引擎的可重复读隔离级别可以解决读幻象的问题，它是通过间隙锁机制实现的。具体来说，当select \* from t where d=5 for update;进行加锁时，除了加上行级锁，还会加上间隙锁。

在(0,0,0), (5,5,5), (10,10,10), (15,15,15), (20,20,20), (25,25,25)六条记录中，总共有7个间隙锁：(负无穷, 0\], (0,5\], (5,10\], (10,15\], (15,20\], (20,25\], (25,正无穷)。当给

在可重复读隔离级别之下，InnoDB存储引擎采用Next-Key Locking机制来加锁，而在读提交隔离级别之下，InnoDB仅仅采用Record Lock机制。

三、四种事务隔离级别

四种隔离级别分别为：读未提交、读提交、可重复读、可串行化，其隔离性从左到右越来越强，并发度从左到右越来越低，但是，一般还是使用可重复读，因为在并发场景下，完全不存在任何问题。

四种隔离级别及各自存在的并发一致性问题如下图所示：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMwOTczNDMx_size_16_color_FFFFFF_t_70 7][]

注意：上面这个图只针对MySQL数据库系统的InnoDB存储引擎，不针对其他数据库。因为InnoDB存储引擎个可重复读隔离级别采用Next-Key Locking机制来避免读幻象的问题，而其他数据库如Oracle则只能在可串行化隔离级别下解决此问题。

四、总结

（1）InnoDB使用共享锁，提高读读并发；使用互斥锁，保证同一行记录修改与删除的串行性，从而保证数据强一致；

（2）InnoDB使用MVCC，提高写读并发

（3）InnoDB使用插入意向锁，提高插入并发

参考资料：

1. 《MySQL技术内幕 InnoDB存储引擎》

2. [https://www.itcodemonkey.com/article/8000.html][https_www.itcodemonkey.com_article_8000.html]

3. 《MySQL实战45讲》

4. [https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html\#innodb-intention-locks][https_dev.mysql.com_doc_refman_5.7_en_innodb-locking.html_innodb-intention-locks]

5. 《高性能MySQL》

[20191224152130425.png]: https://img-blog.csdnimg.cn/20191224152130425.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMwOTczNDMx_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20191224211735213.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMwOTczNDMx,size_16,color_FFFFFF,t_70
[20191226125825156.png]: https://img-blog.csdnimg.cn/20191226125825156.png
[20191226130448484.png]: https://img-blog.csdnimg.cn/20191226130448484.png
[20191226130536416.png]: https://img-blog.csdnimg.cn/20191226130536416.png
[20191226130624255.png]: https://img-blog.csdnimg.cn/20191226130624255.png
[20191226130718294.png]: https://img-blog.csdnimg.cn/20191226130718294.png
[20191226134911954.png]: https://img-blog.csdnimg.cn/20191226134911954.png
[20191226135055366.png]: https://img-blog.csdnimg.cn/20191226135055366.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMwOTczNDMx_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20191226135516222.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMwOTczNDMx,size_16,color_FFFFFF,t_70
[20191226140200262.png]: https://img-blog.csdnimg.cn/20191226140200262.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMwOTczNDMx_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20191226140406107.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMwOTczNDMx,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMwOTczNDMx_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/20191226141628122.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMwOTczNDMx,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMwOTczNDMx_size_16_color_FFFFFF_t_70 4]: https://img-blog.csdnimg.cn/20191226142207629.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMwOTczNDMx,size_16,color_FFFFFF,t_70
[20191226142925864.png]: https://img-blog.csdnimg.cn/20191226142925864.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMwOTczNDMx_size_16_color_FFFFFF_t_70 5]: https://img-blog.csdnimg.cn/20191226143940648.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMwOTczNDMx,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMwOTczNDMx_size_16_color_FFFFFF_t_70 6]: https://img-blog.csdnimg.cn/20191226144938513.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMwOTczNDMx,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMwOTczNDMx_size_16_color_FFFFFF_t_70 7]: https://img-blog.csdnimg.cn/20191226150048974.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMwOTczNDMx,size_16,color_FFFFFF,t_70
[https_www.itcodemonkey.com_article_8000.html]: https://www.itcodemonkey.com/article/8000.html
[https_dev.mysql.com_doc_refman_5.7_en_innodb-locking.html_innodb-intention-locks]: https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html#innodb-intention-locks