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

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 一部分存在内存中，一部分存在磁盘文件中，和主流的日志框架一样，日志优先存入内存，再异步持久化到磁盘。

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,指向上个版本的地址，可以通过它找到该记录修改前的信息。

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

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

ReadReview

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

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

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

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

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

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

id	name	trx_id	roll_ptr
1	aa	1	null

id	name	trx_id	roll_ptr
1	bb	2	上个版本的地址

id	name	trx_id	roll_ptr
1	cc	3	上个版本的地址

接着，我们执行一个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事务级别工作的事务就不能保证。是因为它会读取新的版本行数据，导致数据不一致

参考文章：cloud.tencent.com/developer/a…

当前读和快照读的区别

1.快照读

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

除了这俩类

SELECT ... FOR UPDATE
SLECT ... LOCK IN SHARE MODE

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

参考文章：blog.csdn.net/w892824196/…

2.当前读

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

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