MySQL事务详解结合MVCC机制的理解

浅浅的花香味﹌ 2023-09-25 18:43 12阅读 0赞

### MySQL事务的隔离级别 ###

SQL标准定义了四个隔离级别：

*  READ-UNCOMMITTED(读取未提交)：最低的事务隔离级别，允许读取尚未提交的数据变更，可能导致脏读，幻读，不可重复读。
 *  READ-COMMITTED(读取已提交)：可以阻止脏读，但是不可重复度，幻读仍然可能发生。
 *  REPEATABLE-READ(可重复读)：同一事务中，多次一样的查询结果相同，**除非数据是被本身事务修改**，可以阻止脏读和不可重复读，幻读仍然可能发生

脏读 ——读未提交(read-uncommited)

脏读，也叫读未提交。

首先，第一个连接开启事务，第二个连接也开启事务。第二个连接修改数据，但并未提交。与此同时，第一个连接读取修改后的数据。然而此时第二个事务又回滚。

所以，第一个连接所读取的东西就是就是一个脏数据（因为未的数据也会去读）。因为它和现在的mysql表里面的数据不符合，因为更新sql已经回滚了。

避免脏读 —— 读已提交(read committed)

首先，第一个连接开启事务，第二个连接也开启事务。第二个连接修改数据，但并未提交。与此同时，第一个连接读取，但它只会读已经提交的数据，所以不会读到修改后的数据。

此时，第二个连接提交事务。第一个连接再读，果然读到了更新后的数据。

不可重复读(reapeatable-read)

不可重复读的定义是，数据库访问中，一个事务范围内，两个或多个相同的查询，却返回了不同的结果。

上面的 `避免脏读 —— 读已提交`就会出现这样的情况

可重复读

如果将事务隔离级别设置为可重复读，那么即使第二个连接修改了数据且提交了事务。第一个连接在同一事务内，读取到的数据也是一样的。

幻读

举个例子，什么是幻读？

第一个连接开启事务，查询 条件为 x 的数据有一条。

此时，第二个连接也开启事务，并且插入一条 条件为 x 的数据。

如果第一个连接用快照读，查出来的数据和之前一样，是一条，但用当前读的时候，查到了两条数据，里面包括了第二个连接新增的。

这就是幻读现象。

**怎么解决幻读？** (serializable)

解决幻读的方式有很多，但是他们的核心思想是在操作某张表数据的时候，另一个数据不允许删除或者新增这张表的数据。

1.  将事务的隔离级别调整为 `SERIALIZABLE`
2.  在可重复读的事务级别下，给事务操作的这张表添加表锁
3.  在可重复读的事务级别下，给事务操作的这行表添加Next-key Lock（Record Lock+Gap Lock）

### 深入理解MVCC机制 ###

在mysql事务中，要么全部执行，要么全部回滚。事务的核心是基于两个文件 **redo log** 和 **undo log**

redo log

redo log 叫重做日志，是记录物理数据变化的日志，使用DML对数据的修改操作都会产生redo log。它保证了数据的**持久性**

正因为redo log 记录了一系列的 DML操作，因此它也可进行数据恢复。redo log 一部分存在内存中，一部分存在磁盘文件中，和主流的日志框架一样，**日志优先存入内存，再异步持久化到磁盘**。

![format_png][]

undo log

uodo log 是回滚日志，两个作用：**提供回滚操作**和**多个行版本控制（MVCC：Muti-Version-Concurrency-Control）**

uodo log 主要记录数据的逻辑变化，是逻辑日志。当delete 一条记录，undo log会记录一条对应的insert记录。当update一条记录，会记录一条相反的update log。因此，当rolloback的时候就可以直接读undo log 来回滚。

多行版本控制（MVCC）的时候，也是通过undo log 来实现的。

MVCC原理

**版本链**

MySQL每个行记录逻辑上是个链表，这个链表存在于undo log中。

*  trx\_id,最近修改的事务的id。每次新增一个事务。该事务id会递增，因此trx\_id可以表示事务开始的先后顺序
 *  roll\_pointer,指向上个版本的地址，可以通过它找到该记录修改前的信息。

![format_png 1][]

> 总的来说，版本链的组成是 数据 + 正在修改它的事务id + 上个版本的地址（回滚需要）

每次更新后，都会将旧值放入undo log 中，本质就是记录一个旧的版本，更新次数多了，这个版本会因为 roll-ptr形成一个链表，我们称之为版本链。

**ReadReview**

MVCC仅仅在read-commited和repeatable-read两个隔离级别下工作。

区别在于两者生成readreview的策略不同。

对于read-committed(读已提交)和reapeatable-read两个隔离级别的事务来说，必须保证读到的是已经提交过的事务。

因此我们需要判断，版本链中的哪个版本对于当前事务来说是可见的。这就是readReview诞生的意义。

ReadReview 里有个id 列表 trx\_ids，来存储的是当前活跃的读写事务，也就是还没有commit 和 rollback的事务。

举个例子：现在有一个版本链

<table> 
 <thead> 
  <tr> 
   <th>id</th> 
   <th>name</th> 
   <th>trx_id</th> 
   <th>roll_ptr</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>1</td> 
   <td>bb</td> 
   <td>2</td> 
   <td>上个版本的地址</td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <thead> 
  <tr> 
   <th>id</th> 
   <th>name</th> 
   <th>trx_id</th> 
   <th>roll_ptr</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>1</td> 
   <td>cc</td> 
   <td>3</td> 
   <td>上个版本的地址</td> 
  </tr> 
 </tbody> 
</table>

接着，我们执行一个sql语句：

update user name = 'dd' where id = 1
    复制代码

但没有commit。此时readReview就会把这个事务放入 trx\_ids中 【3】（trx\_ids是为了记录未完成的事务）

由于3被放入了trx\_ids中，因此该条记录不可见，继续查询吓一条，返回的结果是 "cc"

总结

所谓的MVCC（Muti-Version Concurrency Control，多版本并发控制）指的是 在read-commited和repeatable-read两个事务隔离级别的事务，在执行普通的SELECT操作的时候，访问的就是版本链的过程。

并且，read-committed和repeatable-read两个隔离级别很大的不同是：

read-commited 每次select 都会生成 一个readreview。

repeatable-read在select 前就生成好了一个ReadReview，之后每次查询都用这个readreview.

为什么repeatable-read能保证多次读取数据一致？

至于为什么repeatable-read能防止多次读结果不一致，是因为事务发生第一次读的时候，就会选定要读取的数据行版本，整个事务内，都读取这个选定好的版本行，不会因为另一个并发事务提交了新的版本行就去选择它。因此每次读取的数据都是一致滴。

同理，read-commited事务级别工作的事务就不能保证。是因为它会读取新的版本行数据，导致数据不一致

### 当前读和快照读的区别 ###

1.快照读

普通读（也称快照读）,就是单纯的SELECT语句。使用uodo log + MVCC 来实现的

除了这俩类

SELECT ... FOR UPDATE
    SLECT ... LOCK IN SHARE MODE
    复制代码

普通读的执行方式是生成 readReview,会检查当前查的数据是否正在被修改（上面提到过，不做赘述），利用MVCC的机制来进行读取，并不会对记录加锁。

2.当前读

当前读，读取的是最新的版本。且需要获取对应记录的锁。

SELECT ... FOR UPDATE
    SELECT ... LOCK IN SHARE MODE
    UPDATE,DELETE,INSERT

[format_png]: https://img-blog.csdnimg.cn/img_convert/6fa7a9ce33d0feeff9e0888b6d21bd78.webp?x-oss-process=image/format,png
[format_png 1]: https://img-blog.csdnimg.cn/img_convert/bee9350ed818528b007547bb0a982210.webp?x-oss-process=image/format,png