一、引入undo log
InnoDB的已提交读和可重复读的底层实现原理：MVCC（多版本并发控制），MVCC提供了一种并发的读取方式，即快照读 ，同一份数据会有多个版本。
InnoDB给我们提供了；两个读取操作：锁定读和非锁定读。
- 锁定读：读取的时候加锁（S锁或X锁）。
- 非锁定读：读取得时候不加锁，MVCC提供的快照读，快照读底层依赖的是undo log回滚日志。
ACD特性用事务日志实现，I 特性用共享锁、排它锁、MVCC 实现。事务日志分为undo log（回滚日志） 和redo log（重做日志）
二、undo log
1. undo log的概念
2. undo log回滚日志的主要作用
- 事务发生错误时回滚日志回滚rollback，我们都知道事务的原子性和一致性，事务要么全部成功，要么全部失败，不能部分成功，部分失败，也就是说当我们事务里包含了一组sql时，执行几条成功了，剩下的失败了，那么就要进行回滚了，这就要把数据更新之前的原始数据保存在回滚日志中，保证事务出错回滚或者我们手动回滚的时候，可以在回滚日志中找到最初的数据。
- 提供了MVCC非锁定读（快照读），底层依赖undo log实现。
3. undo log的数据结构
在MVCC下，针对表的所有记录，除了我们自行设定的字段book_id、book_name、auther
还会添加几个字段
- DB_ROW_ID：MVCC的关系不大，这个是我们创建表的时候，如果没有加PRIMARY KEY，那么InnoDB就自动生成主键列id（DB_ROW_ID），通过这个id作为主键创建索引树，在B+树的叶子节点上存放数据。由于InnoDB的数据和索引是存放在一起的，如果我们没有设置主键，InnoDB会自动生成主键
- DB_TRX_ID：事务ID，我们每打开一个客户端session，输入begin，向服务器请求开启一个事务。事务开启请求发到MySQL server上，MySQL server为每个事务都会分配一个全局的，不冲突的事务ID（InnoDB存储引擎分配的，因为它才支持事务）。当某个事务修改数据时，DB_TRX_ID放的就是该事务的ID，同一个事务无论怎么更改数据，这个事务ID都不会改变
- DB_ROLL_PTR：回滚指针，我们看到，存放的是地址，这个地址表示的是一个数据的内存的位置，看起来是一个链表，上图中的这个橙色表是最后的成品，那么这个表是怎么变来的呢？
最初的时候表是这样的：
现在有一个ID为1001的事务来更改这条数据，这个事务把book_name改成了“笑傲江湖（吕颂贤）”
此时数据涉及到修改了，修改的数据存放在当前这个表中，那修改之前的数据怎么办？防止事务回滚恢复修改前的状态，需要将最初的数据存放在undo log中！
现在undo log的数据结构如下：
MVCC创建的表和MVCC将来提供的快照读的功能相关，就是给表增加两列：事务ID和回滚指针，指针指向的就是修改前的数据，修改前的数据放在undo log，当前位置放的当前修改后的数据，哪个事务改的事务ID就写相应事务的ID号，回滚指针把旧数据和新数据全部串联在一个链表中，所以从当前行的回滚指针就可以访问到之前的旧数据，进行回滚就很简单了。
三、undo log举例
原始user表的内容：
MVCC对这个表会增加两列：事务ID（更改当前事务的ID号）和回滚指针（指向undo log回滚日志上的地址，当前最新修改和原始数据是串在一个链表中的）
现在把id=7的数据的age改成16，如图所示：
如果我们增加一个数据，由于新增的数据没有对应的老版本，所以对应的undo log为NULL
回滚的时候我们发现是NULL，就知道是insert增加的数据，直接执行Insert的反操作delete就可以了。
同样如果我们要修改刚insert的数据，把id=23的age改成23
在已提交读和可重复读这两种隔离级别下，当我们去读数据的时候，不像我们前面学的串行化通过共享锁、排它锁或间隙锁来实现的，而是通过MVCC的快照读实现。