mysql事务、mvcc

MVCC 

参考 https://blog.csdn.net/SnailMann/article/details/94724197

Mvcc 指的是 多版本并发控制， 主要用来避免在并发情况下写操作对读操作的阻塞。减少锁的使用进而提高并发能力。

 MVCC 就是为了实现读-写冲突不加锁，而这个读指的就是快照读, 而非当前读。当前读实际上是一种加锁的操作，是悲观锁的实现

MVCC主要依赖于 记录中的 3个隐式字段、undolog 以及 Read View 这三个部分来实现的。

一、undolog ： 回滚日志， 在我们对数据进行修改的时候方便我们回滚的一个日志记录，保存的是数据的历史版本状态。可以认为当delete一条记录时，undo log中会记录一条对应的insert记录，反之亦然，当update一条记录时，它记录一条对应相反的update记录，使用sql保证数据能恢复成原来的状态。

当不同事务对同一条记录做修改的时候， 记录的undolog会通过DB_ROLL_PTR字段形成一条链表，而链尾是最早的历史记录。

当执行rollback时，就可以从undo log中的逻辑记录读取到相应的内容并进行回滚。

二、Mysql隐藏字段 ：

Mysql创建的数据中每一行都会包含几个用户不可见的字段 ：

DB_TRX_ID ： 创建或者最后一次修改该记录的事务id

DB_ROW_ID ： 隐藏主键(如果我们没有给表指定主键，则表用这个作为主键，对应的非聚簇索引的叶子节点存到这个)

DB_ROLL_PTR ： 回滚指针， 指向上一个版本在 undolog 中地址。

三、readview：事务在进行快照读的时候产生的读视图。

包含以下部分：

trx_list ： 系统活跃的事务id

up_limit_id ： 列表中事务的最小id

low_limit_id ： 系统尚未分配的下一个事务id

当前读 ： 读取的是数据的最新版本， 除了 select 操作，其他的都是当前读。

快照读：读取的是undolog中的历史版本， 只有不加锁的 select 会进行快照读。

需要注意的是， 快照读只有在事务开启后执行了 select 的时候才会对对应的数据生成，如果没有进行对应的 select， 就不会生成快照读， 则其他事务的修改当前事务是可以读到的。

可见性算法 :

说白了 Read View 就是事务进行快照读操作的时候生产的读视图 (Read View)，在该事务执行的快照读的那一刻，会生成数据库系统当前的一个快照，记录并维护系统当前活跃事务的 ID (当每个事务开启时，都会被分配一个 ID , 这个 ID 是递增的，所以最新的事务，ID 值越大)

所以我们知道 Read View 主要是用来做可见性判断的, 即当我们某个事务执行快照读的时候，对该记录创建一个 Read View 读视图，把它比作条件用来判断当前事务能够看到哪个版本的数据，既可能是当前最新的数据，也有可能是该行记录的undo log里面的某个版本的数据。

Read View遵循一个可见性算法，主要是将要被修改的数据的最新记录中的 DB_TRX_ID（即当前事务 ID ）取出来，与系统当前其他活跃事务的 ID 去对比（由 Read View 维护），如果 DB_TRX_ID 跟 Read View 的属性做了某些比较，不符合可见性，那就通过 DB_ROLL_PTR 回滚指针去取出 Undo Log 中的 DB_TRX_ID 再比较，即遍历链表的 DB_TRX_ID（从链首到链尾，即从最近的一次修改查起），直到找到满足特定条件的 DB_TRX_ID , 那么这个 DB_TRX_ID 所在的旧记录就是当前事务能看见的最新老版本

具体算法:

1. 首先比较 DB_TRX_ID < up_limit_id , 如果小于，则当前事务能看到 DB_TRX_ID 所在的记录，如果大于等于进入下一个判断
2. 接下来判断 DB_TRX_ID >= low_limit_id , 如果大于等于则代表 DB_TRX_ID 所在的记录在 Read View 生成后才出现的，那对当前事务肯定不可见，如果小于则进入下一个判断
3. 判断 DB_TRX_ID 是否在活跃事务之中，trx_list.contains (DB_TRX_ID)，如果在，则代表我 Read View 生成时刻，你这个事务还在活跃，还没有 Commit，你修改的数据，我当前事务也是看不见的；如果不在，则说明，你这个事务在 Read View 生成之前就已经 Commit 了，你修改的结果，我当前事务是能看见的

RC ： 读已提交

RR ： 读未提交

redolog、binlog与两段提交。

1、binlog：

Binlog是server层的日志，主要做mysql功能层面的事情。

Binlog中会记录所有的逻辑，并且采用追加写的方式。

一般在企业中数据库会有备份系统，可以定期执行备份，备份的周期可以自己设置。

数据备份的原理是根据当前时刻中数据库中的数据，生成插入语句sql文件。

恢复数据的过程：

先找到最近一次的全量备份数据，再从备份的时间点开始，将备份的binlog取出来，重放到要恢复的那个时刻。

2、redolog：

redo是innodb独有的，binlog是所有引擎都可以使用的。

redo是物理日志，记录的是在某个数据页上做了什么修改，binlog是逻辑日志，记录的是这个语句的原始逻辑。

redo是循环写的，空间会用完，binlog是可以追加写的，不会覆盖之前的日志信息。

Redolog的数据是以顺序读写的方式存储在日志中的， 顺序读写的速度远高于磁盘中的随机读写， 使用redolog可以提高效率。

数据更新的流程：

执行流程：

1、执行器先从引擎中找到数据，如果在内存中直接返回，如果不在内存中，查询后返回

2、执行器拿到数据之后会先修改数据，然后调用引擎接口重新吸入数据

3、引擎将数据更新到内存，同时写数据到redo中，此时处于prepare阶段，并通知执行器执行完成，随时可以操作

4、执行器生成这个操作的binlog

5、执行器调用引擎的事务提交接口，引擎把刚刚写完的redo改成commit状态，更新完成

redo log为什么需要两阶段提交?

▪场景一、先写redo log后写binlog:假设在redo log写完，binlog还没有写完的时候，MySQL进程异常重启。由于我们前面说过的，redo log写完之后，系统即使崩溃，仍然能够把数据恢复回来，所以恢复后这一行c的值是1。但是由于binlog没写完就crash了，这时候binlog里面就没有记录这个语句。因此，之后备份日志的时候，存起来的binlog里面就没有这条语句。然后你会发现，如果需要用这个binlog来恢复临时库的话，由于这个语句的binlog丢失，这个临时库就会少了这一次更新，恢复出来的这一行c的值就是0，与原库的值不同。

场景二、先写binlog后写redo log:如果在binlog写完之后crash，由于redo log还没写，崩溃恢复以后这个事务无效，所以这一行c的值是0。但是binlog里面已经记录了“把c从0改成1”这个日志。所以，在之后用binlog来恢复的时候就多了一个事务出来，恢复出来的这一行c的值就是1，与原库的值不同。

说白了就是因为我的事务要保证redolog中的数据最终和binlog中的保持一致， 所以我给redolog设置了一个状态， 用来标记binlog中是否写入成功。

事务的四大特性以及实现基础

【原子性】 ： 依赖 undolog 实现。

【隔离性】 ： 依赖 MVCC 实现。

【持久性】 ： 依赖 redolog中的两段提交保证数据不丢失， 写数据的时候先写到顺序读写的日志文件再写到随机读写磁盘文件中， 如果实际的数据没有写入到磁盘，只要日志文件保存成功，数据就不会丢失，可以根据日志文件来进行数据恢复 。

【一致性】 依赖 原子性、 隔离性、 持久性实现。