Mysql的事务原理与MVCC概念解析

一.事务的主要原理：

1.1 事务的简介：

事务是一组操作的集合，它是不可分割的工作单位，事务会把所有的操作作为一个整体一起向系统提交或者撤销操作请求，即这些操作要么同时成功要么同时失败。

1.2 事务的特性：

  • 原子性（Atomicity）：事务是不可分割的最小操作单元，要么全部成功，要么全部失败。
  • 一致性（Consistency）：事务完成时，必须使所有的数据都保持一致状态。
  • 隔离性（Isolation）：数据库系统提供的隔离机制，保证事务在不受外部并发操作影响的独立环境下运行
  • 持久性（Durability）：事务一旦提交或回滚，它对数据库中的数据的改变就是永久的。

1.3 事务的隔离级别：

对于现在高并发的环境下，已经存在多个线程同时访问数据的情形，所以就必然导致并发事务的相关问题。接下来先介绍并发事务中存在的几种情况：
(1)脏读问题：一个事务读到另外事务还未提交的数据：

上面的情形就是线程2在更改响应的数据以后，线程1读到线程2未提交的数据，如果此时线程1事务回滚会造成数据不一致的情况。

(2)不可重复读问题：一个事务先后读取同一条记录，但是两次的读取的数据不一致，称之为不可重复读。

此时同样会造成数据不一致的情形。

注意脏读和不可重复读的区别是一个读到另一个线程未提交的数据，另一个读到线程已经提交的数据。

(3)幻读：一个事务按照查询的要求查询数据时候发现改数据不存在，但是在插入数据时候又发现这行数据已经存在，好像出现了幻影。

面对以上问题Mysql数据为我们解决的相应的问题：
我们可以设置数据库的隔离级别以应对多线程的并发问题：
1.Read uncommitted:解决不了脏读，不可重复读，幻读的问题，因为多线程并发就是因为多个线程读取到了其他线程并未提交的数据，从而导致的数据不一致性问题
2.Read committed:可以解决脏读问题，但是解决不了不可重复读和幻读的问题
3.Repeatable Read(为Mysql的默认的模式)：可以解决脏读问题不可重复读问题，但是解决不了幻读问题
4.Serializable:全部问题都可以解决。

1.4 事务的原理：

其实研究事务的原理就是通过研究InnoDB是如何保证事务的四大特性的，主要是分成两个部分：

(1)对于事务当中的原子性，一致性，持久性：
   我们采用redo.log与undo.log来完成

(2)对于事务当中的隔离性：
   我们采取锁机制与MVCC

1.4.1 redo.log:

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

(1)首先先来看一下如果不加redolog会发生什么：

我们知道，在InnoDB引擎中的内存结构中，主要的内存区域就是缓冲池，在缓冲池中缓存了很多的数据页。 当我们在一个事务中，执行多个增删改的操作时，InnoDB引擎会先操作缓冲池中的数据，如果缓冲区没有对应的数据，会通过后台线程将磁盘中的数据加载出来，存放在缓冲区中，然后将缓冲池中的数据修改，修改后的数据页我们称为脏页。 而脏页则会在一定的时机，通过后台线程刷新到磁盘中，从而保证缓冲区与磁盘的数据一致。 而缓冲区的脏页数据并不是实时刷新的，而是一段时间之后将缓冲区的数据刷新到磁盘中，假如刷新到磁盘的过程出错了，而提示给用户事务提交成功，而数据却没有持久化下来，这就出现问题了，没有保证事务的持久性。

(2)首先先来看一下如果加redolog会发生什么：

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

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

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

（4）Mysql的两阶段提交：

对于Mysql Innodb存储引擎而言，每次修改后，不仅需要记录Redo log还需要记录Binlog，而且这两个操作必须保证同时成功或者同时失败，否则就会造成数据不一致。为此Mysql引入两阶段提交。
步骤：

大致分成四个步骤三个间隙阶段：
1.(步骤一)更改数据
2.(间隙一)此时如果服务器发生断电，redolog与binlog都没有持久化因此最终数据一致
3.(步骤二)写redolog(prepare状态)
4.(间隙二)此时如果服务器断电，重启后，检查redolog状态，如果有且处于prepare状态，查看是否存在binlog,有的话正常提交，没有话则删除处于prepare状态的redolog
5.(步骤三)写binlog
6.(间隙三)此时断电，重启后，查看redolog和binlog只有两者都存在且redolog处于prepare状态则正常提交事务，否则删除log
7.(步骤四)提交事务commit状态

1.4.2 undo.log

回滚日志，用于记录数据被修改前的信息 , 作用包含两个 : 提供回滚(保证事务的原子性) 和 MVCC(多版本并发控制) 。
undo log和redo log记录物理日志不一样，它是逻辑日志。可以认为当delete一条记录时，undolog中会记录一条对应的insert记录，反之亦然，当update一条记录时，它记录一条对应相反的update记录。当执行rollback时，就可以从undo log中的逻辑记录读取到相应的内容并进行回滚。
Undo log销毁：undo log在事务执行时产生，事务提交时，并不会立即删除undo log，因为这些日志可能还用于MVCC。
Undo log存储：undo log采用段的方式进行管理和记录，存放在前面介绍的 rollback segment回滚段中，内部包含1024个undo log segment。

二.MVCC:

2.1 基本概念：

当前读：

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

快照读：

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

  • Read Commited： 每一次select,都生成一个快照读
  • Repeatable Read:开启事务后第一个select 语句才是快照读的地方
  • Serializable:快照读会退化成当前读
MVCC：

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

2.2 隐藏字段：


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

进入服务器中的 /var/lib/mysql/itcast/ , 查看stu的表结构信息, 通过如下指令:

ibd2sdi stu.ibd

2.3 undolog：

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

版本链：

有一张表原始数据为：


并发下事务同时访问这张表：
A. 第一步：

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

B.第二步：

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

C. 第三步：

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

2.4 readView:

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

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

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

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

2.5 原理分析：

2.5.1 RC隔离级别：

注意:在RC隔离级别下，在事务中每执行一次快照读时则生成一个新的ReadView：
在事务5中，查询了两次id为30的记录，由于隔离级别为Read Committed，所以每一次进行快照读都会生成一个ReadView，那么两次生成的ReadView如下：

因此接下来我们就需要根据版本链规则来判断最终的此次快照返回的读取的数据到底是那个：

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


B.第二次读取快照的具体流程同A：

2.5.2 RR隔离级别：

RR隔离级别下，仅在事务中第一次执行快照读时生成ReadView，后续复用该ReadView。 而RR 是可重复读，在一个事务中，执行两次相同的select语句，查询到的结果是一样的。

结论：这种情况也就使得Mysql在InnoDB引擎下的事务隔离级别Repeatable Read是可以解决不可重复的并发事务的问题的。

posted @ 2023-02-17 18:51  LycCj  阅读(64)  评论(0)  编辑  收藏  举报