事务原理
持久性
持久性本质就是有redo.log来保证的
redo.log
redo.log重做日志记录的是事务提交是数据也的物理修改，用来实现事务的持久性。
该日志文件由两部分组成：重做日志缓冲(redo log buffer)以及重做日志文件(redo log file)，前者是在内存中，后者是在磁盘中。当事务提交后会把所有修改信息都存在该日志文件中，用于刷新脏页到磁盘发生错误时，进行数据恢复使用。
流程
redo.log出现前
redo.log出现后
为什么不每次直接将Buffer Pool中变更的数据页直接刷新到磁盘中？
- 可以这么做，但是会存在严重的性能问题。因为事务的一组操作同时会操作多条记录，这些记录是随机的去操作数据页的，会涉及大量的随机磁盘IO，性能较低。
- 借助Redolog的话，日志文件是追加的，是顺序磁盘IO，性能高于随机磁盘IO，这种机制称之为WAL
- 脏页的数据顺利刷新到磁盘中时，Redolog也就不需要了，所以redolog日志每隔一段时间都会去清理
原子性
事务原子性的实现，需要依赖于undo.log日志
undo.log
回滚日志，用于记录数据被修改前的信息，作用包含：提供回滚和MVCC（多版本并发控制）
undo.log和redo.log记录物理日志不一样，他是逻辑日志。可以认为当delete一条记录时，undo.log中会记录一条对应的insert记录，反之亦然，当update一条记录时，它记录一条与之相反的update。当执行rollback时，就可以从undo.log中的逻辑记录到相应的内容并进行回滚。
undo.log销毁：undo.log在事务执行时产生，事务提交时，并不会立即删除undo.log，因为这些日志可能还用于MVCC。
undo.log存储：undo.log采用段的方式进行管理和记录，存放在rollback segment回滚段中，内部包含1024个undo.log segment。
MVCC
基本概念
当前读
读取的是记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加 锁。对于我们日常的操作，如:select … lock in share mode(共享锁)，select … for update、update、insert、delete(排他锁)都是一种当前读。
快照读
快照读 简单的select(不加锁)就是快照读，快照读，读取的是记录数据的可见版本，有可能是历史数据，不加锁，是非阻塞读。
- Read Committed:每次select，都生成一个快照读。
- Repeatable Read:开启事务后第一个select语句才是快照读的地方。
- Serializable:快照读会退化为当前读。
MVCC
全称 Multi-Version Concurrency Control，多版本并发控制。指维护一个数据的多个版本， 使得读写操作没有冲突，快照读为MySQL实现MVCC提供了一个非阻塞读功能。MVCC的具体实现，还需 要依赖于数据库记录中的三个隐式字段、undo log日志、readView。
MVCC-实现原理
- 记录中的隐藏字段
隐藏字段含义：
| **隐藏字段 ** | 含义 |
|---|---|
| DB_TRX_ID | 最近修改事务ID，记录插入这条记录或最后一次修改该记录的事务ID。 （自增） |
| DB_ROLL_PTR | 回滚指针，指向这条记录的上一个版本，用于配合undo log，指向上一个版本。 |
| DB_ROW_ID | 隐藏主键，如果表结构没有指定主键，将会生成该隐藏字段。 |
在表空间ibd文件中才能看到隐藏字段
#ibd2sdi idb文件名
ibd2sdi stu.ibd
- undo log
回滚日志，在insert、update、delete的时候产生的便于数据回滚的日志。
当insert的时候，产生的undo log日志只在回滚时需要，在事务提交后，可被立即删除。
而update、delete的时候，产生的undo log日志不仅在回滚时需要，在快照读时也需要，不会立即 被删除。
- undo log版本链
第一步
当事务2执行第一条修改语句时，会记录undo log日志，记录数据变更之前的样子; 然后更新记录， 并且记录本次操作的事务ID，回滚指针，回滚指针用来指定如果发生回滚，回滚到哪一个版本。
第二步
当事务3执行第一条修改语句时，也会记录undo log日志，记录数据变更之前的样子; 然后更新记 录，并且记录本次操作的事务ID，回滚指针，回滚指针用来指定如果发生回滚，回滚到哪一个版本。
第三步
当事务4执行第一条修改语句时，也会记录undo log日志，记录数据变更之前的样子; 然后更新记 录，并且记录本次操作的事务ID，回滚指针，回滚指针用来指定如果发生回滚，回滚到哪一个版本。
查询时具体返回哪个版本需要设计MVCC-readview
- ReadView
ReadView(读视图)是 快照读 SQL执行时MVCC提取数据的依据，记录并维护系统当前活跃的事务 (未提交的)id。
ReadView中包含了四个核心字段:
| 字段 | 含义 |
|---|---|
| m_ids | 当前活跃的事务ID集合 |
| min_trx_id | 最小活跃事务ID |
| max_trx_id | 预分配事务ID，当前最大事务ID+1（因为事务ID是自增的） |
| creator_trx_id | ReadView创建者的事务ID |
不同的隔离级别，生成ReadView的时机不同：
- READ COMMITTED：在事务中每一次执行快照读时生成ReadView
- REPEATABLE READ：仅在事务中第一次执行快照时生成ReadView，后续复用该ReadView
READ COMMITTED级别：
在事务5中，查询了两次id为30的记录，由于隔离级别为Read Committed，所以每一次进行快照读
都会生成一个ReadView，那么两次生成的ReadView如下。
那么这两次快照读在获取数据时，就需要根据所生成的ReadView以及ReadView的版本链访问规则， 到undolog版本链中匹配数据，最终决定此次快照读返回的数据。
A. 先来看第一次快照读具体的读取过程:
在进行匹配时，会从undo log的版本链，从上到下进行挨个匹配:
B. 再来看第二次快照读具体的读取过程:
REPEATABLE READ级别：
RR隔离级别下，只是在事务中第一次快照读时生成ReadView，后续都是复用该 ReadView，那么既然ReadView都一样， ReadView的版本链匹配规则也一样， 那么最终快照读返 回的结果也是一样的。
所以，MVCC的实现原理就是通过 InnoDB表的隐藏字段、UndoLog 版本链、ReadView来实现的。 而MVCC + 锁，则实现了事务的隔离性。 而一致性则是由redolog 与 undolog保证。
