事务原理
持久性
持久性本质就是有redo.log来保证的
redo.log
redo.log重做日志记录的是事务提交是数据也的物理修改，用来实现事务的持久性。
该日志文件由两部分组成：重做日志缓冲(redo log buffer)以及重做日志文件(redo log file)，前者是在内存中，后者是在磁盘中。当事务提交后会把所有修改信息都存在该日志文件中，用于刷新脏页到磁盘发生错误时，进行数据恢复使用。
流程
redo.log出现前
Buffer pool(缓冲池)：缓冲池中缓冲数据页的信息
当客户端发起事务操作时， 首先去缓冲区中查找是否有要更新的数据，若没有，会通过后台线程去磁盘中读取出对应的数据，然后缓存到缓冲区中。
然后直接操作缓冲区中的数据，缓冲区中的数据发生变更，但磁盘中的数据并未发生变更。此时的数据也称之为脏页，一定时间后，要通过后台线程将脏页中的数据刷新到磁盘中，缓冲区中的数据就与磁盘中的数据保持一致了。
若脏页数据往磁盘中刷新时出错了，此时会导致内存中的数据并没有刷新到磁盘中，持久性无法得到保障。
redo.log出现后
当我们对缓冲区中的数据进行增删改之后，首先会将这些数据记录到Redolog buffer(重做日志缓冲区)中，记录数据页的物理变化，事务在提交时，会将Redolog Buffer中数据页的变化直接刷新到磁盘中，持久化的保存到磁盘文件中。一段时间后会进行脏页刷新，如果出错，可以通过redo.log进行恢复，因为在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。
undo.log会记录数据在更新之前的信息，当事务执行失败时，进行回滚时，就需要依赖undo.log。
一旦事务提交或者回滚了，undo.log也就不需要了，但是并不会立即删除，会检查当前undo.log数据记录是否涉及MVCC。
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 | 隐藏主键，如果表结构没有指定主键，将会生成该隐藏字段。 |
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，回滚指针，回滚指针用来指定如果发生回滚，回滚到哪一个版本。
不同事务或相同事务对同一条记录进行修改，会导致该记录的undolog生成一条 记录版本链表，链表的头部是最新的旧记录，链表尾部是最早的旧记录。
查询时具体返回哪个版本需要设计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保证。