MySQL的InnoDB引擎如何保证事务的持久性和隔离性

redo log

重做日志，记录的是事务提交时数据页的物理修改，用来实现事务的持久性。

分为重做日志缓冲（redo log buffer）在内存、重做日志文件（redo log file）在磁盘。

有了redo log，可以保证事务一定能成功执行（只要提交了）。当然，如果回滚的话，就表明这个事务没有成功提交，那就得靠undo leg进行回滚。

假设没有redo log的过程：

在来一个DML语句请求的时候，缓冲页会看有没有该数据（不考虑change buffer），没有的话从磁盘中读取到缓冲页，然后直接在缓冲页中操作该数据，这个时候当前页为脏页，需要进行刷新，但是如果在刷新的过程出错，怎么办？ ——  > 就需要靠redo log文件。

正常过程：

操作完缓冲页的数据的时候，也会写入redo log Buffer（也在内存中）中，然后redo log Buffer再刷新到redo log（磁盘）中

注：当redo log持久化完成时，可以认为该事务成功提交。

redo log一方面可以保证数据的成功持久化，还有一点WAL，即write-Ahead Logging：因为日志文件刷新过程是追加的，即顺序写的IO性能远快于随机写，如果是缓冲页直接刷新到磁盘中，那么当前为随机写，性能非常低。

等到脏页刷新完成后，可以认为redo log不需要了，进行定期清理，等下一个事务需要的时候，又往里面填写内容，文件不会删除，而是重复利用。两个redo log文件循环写的。

undo Log

一方面提供回滚，里面记录的是一条反向的sql语句（比如delete ，记录的就是insert），当执行Rollback时，可以从undo Log中读取相应内容。并且该文件是在事务执行的时候产生，事务提交也不会立即删除，因为还要考虑后续应用到MVCC。

MVCC

多版本并发控制。维护一组记录的多个版本，使得读写操作不会冲突。快照读为mySQL实现MVCC提供了非阻塞读。

当前读

读取的是记录的最新版本，读取时保证其他并发事务不能修改当前记录（因此会加锁）。

如select…lock in share mode（共享锁） ,select… for update ，update , insert ,delete(排他锁)

快照读

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

RC：每次select都生成一个快照读。

RR：开启事务后的第一个select语句才是快照读，后面不管怎么读，都是复用。

Serializable：快照读会退化为当前读。

MVCC的具体实现依赖于：

隐藏字段

除了显示字段以外还有2~3个隐藏字段，显示字段就是我们设计表的时候设置的字段

只有当表没有主键且没有唯一索引的时候才会有隐藏主键。

undo log什么时候会删除？

回滚日志，在insert的时候，产生undo log日志在事务提交后，可被立即删除，因为insert语句只有在回滚的时候被需要，进行快照读的时候不需要。

而update、delete不仅考虑回滚，还需要考虑快照读，不会被立即删除。

回滚就是指在当前事务提交失败，则需进行回滚；快照读是指当前事务需要读取之前的事务对（当前事务需要读取的）数据的历史版本。

版本链

DB_TRX_ID 用于记录最近修改这一行数据的事务ID，事务ID是自增的。

DB_ROLL_PTR是一个指针，用来指向上一条数据，即该条数据通过指针可以找到上一条（被更新前）

readview（读视图）

快照读SQL执行时，MVCC提取数据的依据，记录并维护系统当前活跃的事务（未提交的）id

即，每次做查询的时候，MVCC都会给一个图表。

举个例子：按照上面规则（规则只需要理解，不须强行记忆）

当前快照读为事务5生成的readview，然后根据当前事务ID，一个一个通过规则去找，发现4和3都不行，2可以。

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

RC，读已提交：在事务中每一次执行快照读（每次做查询）的时候生成readview

RR，可重复读，仅在当前事务中第一次执行快照读时生成readview，如果当前事务后面还要读，直接复用第一次的readview，即一个事务只有一张readview图。