MySQL 之 InnoDB存储引擎（二）

你的名字 2024-04-01 18:38 185阅读 0赞

## 三 事务原理 ##

### 3.1 事务基础 ###

事务是MySQL区别于NoSQL的重要特征，是保证关系型数据库数据一致性的关键技术。事务可看作是对数据库操作的基本执行单元，可能包含一个或者多个SQL语句。这些语句在执行时，要么都执行，要么都不执行。MySQL事务包含四个特性：

**原子性（Atomicity）**：语句要么全执行，要么全不执行，是事务最核心的特性，事务本身就是以原子性来定义的。实现主要基于undo log日志。

**持久性（Durability）**：保证事务提交后不会因为宕机等原因导致数据丢失。实现主要基于redo log日志。

**隔离性（Isolation）**：保证事务执行尽可能不受其他事务影响。InnoDB默认的隔离级别是RR，RR的实现主要基于锁机制、数据的隐藏列、undo log和类next-key lock机制。

**一致性（Consistency）**：事务追求的最终目标，一致性的实现既需要数据库层面的保障，也需要应用层面的保障。

那实际上，我们研究事务的原理，就是研究MySQL的InnoDB引擎是如何保证事务的这四大特性的

而对于这四大特性，实际上分为两个部分。 其中的原子性、一致性、持久化，实际上是由InnoDB中的两份日志来保证的，一份是redo log日志，一份是undo log日志。 而持久性是通过数据库的锁，加上MVCC来保证的。

![e6db3fbb422f4fd08e3fce9db85d35e5.png][]

### 3.2 redo log ###

重做日志（redo log）是InnoDB引擎层的日志，用来记录事务操作引起数据的变化，记录的是数据页的物理修改。InnoDB引擎对数据的更新，是先将更新记录写入redo log日志，然后会在系统空闲的时候或者是按照设定的更新策略再将日志中的内容更新到磁盘之中。这就是所谓的预写式技术（Write Ahead logging）。这种技术可以大大减少IO操作的频率，提升数据刷新的效率。

该日志文件有两部分组成：**重做日志缓冲**（redo log buffer）以及**重做日志文件**（redo log file），前者是在内存中，后者是在磁盘中。当事务提交之后会把所有的修改信息都保存到该日志文件中，用于在刷新脏页到磁盘的过程中发生错误时，进行数据恢复使用。

**如果没有 redo log 会存在什么问题？**

在 InnoDB 存储引擎中，主要的内存区域就是缓冲池，在缓冲池中缓存了很多数据页，当我们对数据进行操作时，并不会直接去操作磁盘中的数据，而是操作缓冲池中的数据，若缓冲池不存在我们需要的数据，则会通过后台线程将数据从磁盘中加载出来，放到缓冲池中，然后将缓存池中的数据进行修改，修改后的数据页被称之为脏页，而脏页并不会直接刷新到磁盘中，而是在一定的时机，通过后台线程刷新到磁盘中，从而保证缓冲区与磁盘的数据一致，因为缓冲区的脏页数据并不是实时刷新的。如果在一段时间后，脏页刷新到磁盘中的过程中出现了错误，导致数据没有持久化下来，而用户在操作时对缓冲区的数据修改已完成，返回了操作成功，这样就没有保证事务的持久化。

![2bc6934f57ce450287bec4d91891cc68.png][]

那么，如何解决上述的问题呢？ 在InnoDB中提供了一份日志 redo log，接下来我们再来分析一下，通过redolog如何解决这个问题

![fcbe3ee60e024e8880e30b7f05085c5b.png][]

有了redolog之后，当对缓冲区的数据进行增删改之后，会首先将操作的数据页的变化，记录在redolog buffer中。在事务提交时，会将redo log buffer中的数据刷新到redo log磁盘文件中。过一段时间之后，如果刷新缓冲区的脏页到磁盘时，发生错误，此时就可以借助于redo log进行数据恢复，这样就保证了事务的持久性。 而如果脏页成功刷新到磁盘 或 或者涉及到的数据已经落盘，此时redolog就没有作用了，就可以删除了，所以存在的两个redolog文件是循环写的。

redo log有一些细节需要我们注意，redo log日志的大小是固定的，为了能够持续不断的对更新记录进行写入，在redo log日志中设置了两个标志位置，checkpoint和write\_pos，分别表示记录擦除的位置和记录写入的位置。这种结构很像一个循环队列：

![b370f26349cc4976886fbc54a92f7845.png][]

write\_pos与checkpoint中间的空间可用于写入新数据，写入和擦除都是往后推移，循环往复的。当write\_pos追上checkpoint时，表示redo log日志已经写满，这时不能继续执行新的数据库更新语句，需要停下来先删除一些记录，执行checkpoint规则，将buffer中脏数据页和脏日志页都刷到磁盘（脏数据页和脏日志页指还在内存中没有刷到磁盘的数据和日志），腾出可写空间。

讲redo log不得不讲buffer pool，这是在内存中分配的一个区域，包含了磁盘中部分数据页的映射，作为访问数据库的缓冲。当请求读取数据时，会先判断是否在缓冲池命中，如果未命中才会在磁盘上进行检索后放入缓冲池。当请求写入数据时，会先写入缓冲池，缓冲池中修改的数据会定期刷新到磁盘中。这一过程也被称之为刷脏 。

当数据修改时，除了修改buffer pool中的数据，还会在redo log中记录这次操作。当事务提交时，会根据redo log的记录对数据进行刷盘。如果MySQL宕机，重启时可以读取redo log中的数据，对数据库进行恢复，从而保证了事务的持久性，使得数据库获得crash-safe能力。

除了上面提到的对于脏数据的刷盘，实际上redo log日志在记录时，为了保证日志文件的持久化，也需要经历将日志记录从内存写入到磁盘的过程。redo log日志可分为两个部分，一是存在易失性内存中的缓存日志redo log buffer，二是保存在磁盘上的redo log日志文件redo log file。

为了确保每次记录都能够写入到磁盘中的日志中，每次将redo log buffer中的日志写入redo log file的过程中都会调用一次操作系统的fsync操作（fsync函数：包含在UNIX系统头文件\#include 中，用于同步内存中所有已修改的文件数据到储存设备）。在写入的过程中，还需要经过操作系统内核空间的os buffer。

![5eb8ebafd32b4b92bbb58dac7abb24bd.png][]

那为什么每一次提交事务，要刷新redo log 到磁盘中呢，而不是直接将buffer pool中的脏页刷新到磁盘呢 ?

因为在业务操作中，我们操作数据一般都是随机读写磁盘的，而不是顺序读写磁盘。 而redo log在往磁盘文件中写入数据，由于是日志文件，所以都是顺序写的。顺序写的效率，要远大于随机写。 这种先写日志的方式，称之为 WAL（Write-Ahead Logging）

**InnoDB与MVCC**

MVCC只在 READ COMMITTED 和 REPEATABLE READ 两个隔离级别下工作。其他两个隔离级别够和MVCC不兼容, 因为 READ UNCOMMITTED 总是读取最新的数据行, 而不是符合当前事务版本的数据行。而 SERIALIZABLE 则会对所有读取的行都加锁。

### 3.3 undo log ###

回滚日志，用于记录数据被修改前的信息，包含两个作用

*  提供回滚（保证事务的原子性）
 *  MVCC（多版本并发控制）

undo log 和记录物理日志 redo log 不一样，它是逻辑日志，可以认为当 delete 一条记录时，undo log 中会记录一条对应的 insert 记录，防止亦然，当 update 一条记录时，它会记录一条相反的 update 记录，当进行回滚时，就可以从 undo log 中的逻辑记录中读取到相应的内容进行回滚。

**undo log销毁**：undo log 在事务执行时产生，事务提交时，并不会立即删除 undo log，因为这些日志还可能用户 MVCC。

**undo log存储**：undo log是采用段(segment)的方式来记录的，每个undo操作在记录的时候占用一个undo log segment，另外，undo log也会产生redo log，因为undo log也要实现持久性保护。

innodb 存储引擎对 undo 的管理采用段的方式。\*\*rollback segment称为回滚段，每个回滚段中有1024个 undo log segment

在以前老版本，只支持1个rollback segment，这样就只能记录1024个undo log segment。后来MySQL5.5可以支持128个rollback segment，即支持128\*1024个undo操作，还可以通过变量 innodb\_undo\_logs (5.6版本以前该变量是 innodb\_rollback\_segments )自定义多少个rollback segment，默认值为128。

undo log默认存放在共享表空间中。

**参考文献：**

[【MySQL （七） | 详细分析MySQL事务日志 undo log】 - 腾讯云开发者社区-腾讯云][MySQL _ _ _MySQL_ undo log_ - _-]

[MySQL事务原子性之UndoLog，图文结合带你直击核心 - 知乎][MySQL_UndoLog_ -]

## 四 MVCC ##

### 4.1 基本概念 ###

就是多版本并发控制。MVCC 是一种并发控制的方法，一般在数据库管理系统中，实现对数据库的并发访问。

为什么需要MVCC呢？数据库通常使用锁来实现隔离性。最原生的锁，锁住一个资源后会禁止其他任何线程访问同一个资源。但是很多应用的一个特点都是读多写少的场景，很多数据的读取次数远大于修改的次数，而读取数据间互相排斥显得不是很必要。所以就使用了一种读写锁的方法，读锁和读锁之间不互斥，而写锁和写锁、读锁都互斥。这样就很大提升了系统的并发能力。之后人们发现并发读还是不够，又提出了能不能让读写之间也不冲突的方法，就是读取数据时通过一种类似快照的方式将数据保存下来，这样读锁就和写锁不冲突了，不同的事务session会看到自己特定版本的数据。当然快照是一种概念模型，不同的数据库可能用不同的方式来实现这种功能。

#### 4.1.1 当前读 ####

读取的是记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁。对于我们日常的操作，如：select ... lock in share mode(共享锁)，select ...for update、update、insert、delete(排他锁)都是一种当前读。

假设要update一条记录，但是另一个事务已经delete这条数据并且commit了，如果不加锁就会产生冲突。所以update的时候肯定要是当前读，得到最新的信息并且锁定相应的记录。

**参考文献：**

[MySQL之当前读 - 简书][MySQL_ -]

#### 4.1.2 快照读 ####

简单的select（不加锁）就是快照读，快照读，读取的是记录数据的可见版本，有可能是历史数据，不加锁，是非阻塞读。

*  Read Committed：每次select，都生成一个快照读。
 *  Repeatable Read：开启事务后第一个select语句才是快照读的地方。
 *  Serializable：快照读会退化为当前读

#### 4.1.3 MVCC ####

全称 Multi-Version Concurrency Control，多版本并发控制。指维护一个数据的多个版本，使得读写操作没有冲突，快照读为MySQL实现MVCC提供了一个非阻塞读功能。MVCC的具体实现，还需要依赖于数据库记录中的三个隐式字段、undo log日志、readView。

### 4.2 隐藏字段 ###

当我们创建了上面的这张表，我们在查看表结构的时候，就可以显式的看到这三个字段。 实际上除了这三个字段以外，InnoDB还会自动的给我们添加三个隐藏字段及其含义分别是：

<table> 
 <tbody> 
 <tr> 
 <td> 隐藏字段 </td> 
 <td> 含义 </td> 
 </tr> 
 <tr> 
 <td> DB_TRX_ID </td> 
 <td> 最近修改事务ID，记录插入这条记录或最后一次修改该记录的事务ID </td> 
 </tr> 
 <tr> 
 <td> DB_ROLL_PTR </td> 
 <td> 回滚指针，指向这条记录的上一个版本，用于配合undo log，指向上一个版本。 </td> 
 </tr> 
 <tr> 
 <td> DB_ROW_ID </td> 
 <td> 隐藏主键，如果表结构没有指定主键，将会生成该隐藏字段。 </td> 
 </tr> 
 </tbody> 
</table>

上述的前两个字段是肯定会添加的， 是否添加最后一个字段DB\_ROW\_ID，得看当前表有没有主键，如果有主键，则不会添加该隐藏字段

### 4.3 undo log ###

当insert的时候，产生的undo log日志只在回滚时需要，在事务提交后，可被立即删除。而update、delete的时候，产生的undo log日志不仅在回滚时需要，在快照读时也需要，不会立即被删除

**版本链**

有一张表原始数据为：

![34a60bdc13634ad4aefc167936ae544f.png][]

DB\_TRX\_ID : 代表最近修改事务ID，记录插入这条记录或最后一次修改该记录的事务ID，是自增的。

DB\_ROLL\_PTR ： 由于这条数据是才插入的，没有被更新过，所以该字段值为null。

然后，有四个并发事务同时在访问这张表

![d9e9c2b000454f409a5a8d5cabc7f735.png][]

当事务2执行第一条修改语句时，会记录undo log日志，记录数据变更之前的样子; 然后更新记录，并且记录本次操作的事务ID，回滚指针，回滚指针用来指定如果发生回滚，回滚到哪一个版本。

![f936bd001d964d1da098f253fe8c1c7a.png][]

![a9c4ce051d18478a9bc5af7302ed55b8.png][]

当事务3执行第一条修改语句时，也会记录undo log日志，记录数据变更之前的样子; 然后更新记录，并且记录本次操作的事务ID，回滚指针，回滚指针用来指定如果发生回滚，回滚到哪一个版本

![837e94782a374716966a2c0152761426.png][]

![fee747df6c8b40778c500860271a9202.png][]

当事务4执行第一条修改语句时，也会记录undo log日志，记录数据变更之前的样子; 然后更新记录，并且记录本次操作的事务ID，回滚指针，回滚指针用来指定如果发生回滚，回滚到哪一个版本。

![a6eb3f21b853486496290a4cec092ed8.png][]

最终我们发现，不同事务或相同事务对同一条记录进行修改，会导致该记录的undolog生成一条记录版本链表，链表的头部是最新的旧记录，链表尾部是最早的旧记录。

### 4.4 ReadView ###

ReadView（读视图）是 快照读 SQL执行时MVCC提取数据的依据，记录并维护系统当前活跃的事务（未提交的）id。ReadView中包含了四个核心字段：

<table> 
 <tbody> 
 <tr> 
 <td> 字段 </td> 
 <td> 含义 </td> 
 </tr> 
 <tr> 
 <td> m_ids </td> 
 <td> 当前活跃的事务ID集合 </td> 
 </tr> 
 <tr> 
 <td> min_trx_id </td> 
 <td> 最小活跃事务ID </td> 
 </tr> 
 <tr> 
 <td> max_trx_id </td> 
 <td> 预分配事务ID，当前最大事务ID+1（因为事务ID是自增的） </td> 
 </tr> 
 <tr> 
 <td> creator_trx_id </td> 
 <td> ReadView创建者的事务ID </td> 
 </tr> 
 </tbody> 
</table>

而在readview中就规定了版本链数据的访问规则：trx\_id 代表当前undolog版本链对应事务ID。

<table> 
 <tbody> 
 <tr> 
 <td> 条件 </td> 
 <td> 是否可以访问 </td> 
 <td> 说明 </td> 
 </tr> 
 <tr> 
 <td> trx_id ==creator_trx_id </td> 
 <td> 可以访问该版本 </td> 
 <td> 成立，说明数据是当前这个事务更改的。 </td> 
 </tr> 
 <tr> 
 <td> trx_id &lt; min_trx_id </td> 
 <td> 可以访问该版本 </td> 
 <td> 成立，说明数据已经提交了。 </td> 
 </tr> 
 <tr> 
 <td> trx_id &gt; max_trx_id </td> 
 <td> 不可以访问该版本 </td> 
 <td> 成立，说明该事务是在ReadView生成后才开启。 </td> 
 </tr> 
 <tr> 
 <td> min_trx_id </td> 
 <td> 如果trx_id不在m_ids中，是可以访问该版本的 </td> 
 <td> 成立，说明数据已经提交。 </td> 
 </tr> 
 </tbody> 
</table>

不同的隔离级别，生成ReadView的时机不同：

*  READ COMMITTED ：在事务中每一次执行快照读时生成ReadView。
 *  REPEATABLE READ：仅在事务中第一次执行快照读时生成ReadView，后续复用该ReadView。

参考文献（第二篇必看）：

[一文理解Mysql MVCC - 知乎][Mysql MVCC -]

[MySQL中MVCC的正确打开方式（源码佐证）\_Waves\_\_\_的博客-CSDN博客][MySQL_MVCC_Waves_-CSDN]

[MySQL :: MySQL 5.7 Reference Manual :: 14.3 InnoDB Multi-Versioning][MySQL _ MySQL 5.7 Reference Manual _ 14.3 InnoDB Multi-Versioning]

### 4.5 原理分析 ###

#### 4.5.1 RC隔离级别 ####

**RC隔离级别下，在事务中每一次执行快照读时生成ReadView**。

我们就来分析事务5中，两次快照读读取数据，是如何获取数据的?在事务5中，查询了两次id为30的记录，由于隔离级别为Read Committed，所以每一次进行快照读都会生成一个ReadView，那么两次生成的ReadView如下。

![b02ddcc9496c45d881c3276e3e69732d.png][]

那么这两次快照读在获取数据时，就需要根据所生成的ReadView以及ReadView的版本链访问规则，到undolog版本链中匹配数据，最终决定此次快照读返回的数据。

A. 先来看第一次快照读具体的读取过程：

![542eb20b41b94ed29bd4d7cadfa11a2d.png][]

在进行匹配时，会从undo log的版本链，从上到下进行挨个匹配：

![23a9527c58874118b87c857ff5196ab0.png][]

![20dc9534f1024dfca1d461c3981c9eed.png][]

B. 再来看第二次快照读具体的读取过程:

![69a178a15cf74aa1aae2b183fc8e422b.png][]

在进行匹配时，会从undo log的版本链，从上到下进行挨个匹配：

![293d2c718c3a4aa5849a66d5432ec85b.png][]

#### 4.5.2 RR隔离级别 ####

RR隔离级别下，仅在事务中第一次执行快照读时生成ReadView，后续复用该ReadView。 而RR 是可重复读，在一个事务中，执行两次相同的select语句，查询到的结果是一样的。那MySQL是如何做到可重复读的呢? 我们简单分析一下就知道了

![026807770f0e4b66816410cfef1d595c.png][]

我们看到，在RR隔离级别下，只是在事务中第一次快照读时生成ReadView，后续都是复用该ReadView，那么既然ReadView都一样， ReadView的版本链匹配规则也一样， 那么最终快照读返回的结果也是一样的。

所以呢，MVCC的实现原理就是通过 InnoDB表的隐藏字段、UndoLog 版本链、ReadView来实现的。而MVCC + 锁，则实现了事务的隔离性。 而一致性则是由redolog 与 undolog保证。

![8a02d580e4714369bd10039491e77f01.png][]

[e6db3fbb422f4fd08e3fce9db85d35e5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/0caf72860d234bba8859f2734cb2a84e.png
[2bc6934f57ce450287bec4d91891cc68.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/ce48c52b45dc4159be05573efd94ef53.png
[fcbe3ee60e024e8880e30b7f05085c5b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/d4bf9962a56c4ec9a59dcd07f76ea50b.png
[b370f26349cc4976886fbc54a92f7845.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/850ffc1d0cf14bd48dc6f40cd7a43441.png
[5eb8ebafd32b4b92bbb58dac7abb24bd.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/e8ac6971a7cc4a9db6e1f721e267c53a.png
[MySQL _ _ _MySQL_ undo log_ - _-]: https://cloud.tencent.com/developer/article/1497335
[MySQL_UndoLog_ -]: https://zhuanlan.zhihu.com/p/383824552
[MySQL_ -]: https://www.jianshu.com/p/785cef383ed6
[34a60bdc13634ad4aefc167936ae544f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/4db81b27fee64989bb34dd01eac9c316.png
[d9e9c2b000454f409a5a8d5cabc7f735.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/1b4e6c36acfd4725b0140a4dcf32dae5.png
[f936bd001d964d1da098f253fe8c1c7a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/86e12b9cc90a40c3894df27b658d271d.png
[a9c4ce051d18478a9bc5af7302ed55b8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/6bbc3f80cc21488f963e1d9f2dc217da.png
[837e94782a374716966a2c0152761426.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/47c7fd79009745c0970845d1efcdc927.png
[fee747df6c8b40778c500860271a9202.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/b8ad6373ac1d41b8b2d6c14edad466ed.png
[a6eb3f21b853486496290a4cec092ed8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/9dc247f74d164b61b16fd5a63c67fcd9.png
[Mysql MVCC -]: https://zhuanlan.zhihu.com/p/66791480
[MySQL_MVCC_Waves_-CSDN]: https://blog.csdn.net/Waves___/article/details/105295060
[MySQL _ MySQL 5.7 Reference Manual _ 14.3 InnoDB Multi-Versioning]: https://dev.mysql.com/doc/refman/5.7/en/innodb-multi-versioning.html
[b02ddcc9496c45d881c3276e3e69732d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/f0b1432b85674d588d0a43999ecb8ffb.png
[542eb20b41b94ed29bd4d7cadfa11a2d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/5854bf373b8b4d46ab927c28fa0ca41e.png
[23a9527c58874118b87c857ff5196ab0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/b773da2bccb84435a9a606ac16f4d3c5.png
[20dc9534f1024dfca1d461c3981c9eed.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/79bb2310423341dfa87608276d4e9e30.png
[69a178a15cf74aa1aae2b183fc8e422b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/c10370a3dc5a42a88b9f83f2ea03fb46.png
[293d2c718c3a4aa5849a66d5432ec85b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/6e95d87666ec42acab10cd81562d1ddb.png
[026807770f0e4b66816410cfef1d595c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/33394a7aabab4e988f0c338af61cb3a3.png
[8a02d580e4714369bd10039491e77f01.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/cac78a06b201466e9d22a9d0d66145fd.png