浅解释

概念
1、InnoDB 在每行记录后面保存两个隐藏的列，分别保存了数据行的创建版本号和删除版本号。每开始一个新的事务，系统版本号都会递增。事务开始时刻的系统版本号会作为事务的版本号，用来和查询到的每行记录的创建版本号对比。
2、insert：为插入的每一行保存当前系统版本号作为创建版本号。
3、delete：为删除的每一行保存当前系统版本号作为删除版本号。
4、update：插入一条新数据，保存当前系统版本号作为创建版本号。同时保存当前系统版本号作为原来的数据行删除版本号。
演示

事务A插入一条数据，假设当前系统版本号为1
insert into user (id,name) values (1,'Tom');
得到这条数据
id      nanme       create_version        delete_version1       Tom                1      事务A查询数据---根据事务A版本号
select * from user where id = 1;
得到这条数据
id      nanme       create_version        delete_version1       Tom                1      事务B修改数据，事务B版本号为2
update user set name = 'Jerry' where id = 1;
提交后
id      nanme       create_version        delete_version1       Tom                1                    2    1       Jerry              2                     事务A查询数据---根据事务A版本号
select * from user where id = 1;
id      nanme       create_version        delete_version1       Tom                1                    2
**得出结论：可重复读并不会发生不可重复读**事务C删除数据
delete from user where id = 1;
id      nanme       create_version        delete_version1       Jerry              2                    3**得出结论：只有新增和修改会修改数据行的创建版本号、删除和修改会修改数据行的删除版本号**        

深解释

必知一
实际上，InnoDB 会在每行记录后面增加三个隐藏字段：
DB_ROW_ID：行ID，随着插入新行而单调递增，如果有主键，则不会包含该列。
DB_TRX_ID：记录插入或更新该行的事务的事务ID。
DB_ROLL_PTR：回滚指针，指向 undo log 记录。每次对某条记录进行改动时，该列会存一个指针，可以通过这个指针找到该记录修改前的信息 。当某条记录被多次修改时，该行记录会存在多个版本，通过DB_ROLL_PTR 链接形成一个类似版本链的概念。
必知二
每开启一个事务时，系统会给该事务会分配一个事务 Id，事务 A 开启事务的时候会生成一个 事务快照ReadView，主要包含以下几个属性
1、m_ids，当前有哪些事务正在执行，且还没有提交，这些事务的 id 就会存在这里；
2、min_trx_id，是指 m_ids 里最小的值
3、max_trx_id，是指下一个要生成的事务 id。下一个要生成的事务 id 肯定比现在所有事务的 id 都大；
4、creator_trx_id，每开启一个事务都会生成一个 ReadView，而 creator_trx_id 就是这个开启的事务的 id。
必知三
有了这个ReadView，这样在访问某条记录时，只需要按照下边的步骤判断记录的某个版本是否可见：
1）如果被访问版本的trx_id与ReadView中的creator_trx_id值相同，意味着当前事务在访问它自己修改过的记录，所以该版本可以被当前事务访问。
2）如果被访问版本的trx_id小于ReadView中的up_limit_id值，表明生成该版本的事务在当前事务生成ReadView前已经提交，所以该版本可以被当前事务访问。
3）如果被访问版本的trx_id大于ReadView中的low_limit_id值，表明生成该版本的事务在当前事务生成ReadView后才开启，所以该版本不可以被当前事务访问。
4）如果被访问版本的trx_id属性值在ReadView的up_limit_id和low_limit_id之间，那就需要判断一下trx_id属性值是不是在trx_ids列表中。如果在，说明创建ReadView时生成该版本的事务还是活跃的，该版本不可以被访问；如果不在，说明创建ReadView时生成该版本的事务已经被提交，该版本可以被访问。

实现1：自己理解的
不好意思，这个图片转正不过来

实现2：他人博客讲的
1、事务是可以并发执行的，现在有事务 A、事务 B 这两个事务，且这两个都没有提交。事务 A 将会执行多次读操作，来模拟可重复读中多次读取同一行数据的场景。事务 B 则会修改这一行数据

2、事务 A 开启事务的时候会生成一个 ReadView，所以说这个 ReadView 的创建者就是事务 A，事务 A 的事务 id 是 10，所以 creator_trx_id 就是 10。

此时，总共就只有事务 A、事务 B 这两个事务，而且它们都还没有提交，所以说 m_ids 会把这两个事务 id，10、18 都记录下来。min_trx_id 是 m_ids 里面的最小值，10、18 中最小的显然是 10。当前最大的事务 id 是 18，那么下一个事务的 id 就是 19，max_trx_id 就是 19。

ReadView 生成之后，事务 A 就要去 undo log 版本链中读取值了。

现在只有一条 undo log 日志，但这并不意味着事务 A 就能读到这条日志的值 X。它要先判断这行日志的 trx_id 是否小于当前事务的 min_trx_id。看图我们可以很轻松地发现，日志的 trx_id = 8 小于 ReadView 中 min_trx_id = 10。

这就意味着，这个事务 A 开始执行之前，修改这行数据的事务已经提交了，所以事务 A 是可以查到值 X 的。
3、我们继续看，事务 A 第一次读完之后，事务 B 要修改这行数据了。undo log 会为所有写操作生成日志，所以就会生成一条 undo log 日志，并且它的 roll_pointer 会指向上一条 undo log 日志

4、紧接着，事务 A 第二次去读这行数据了，情况如下图所示：

第一次读的时候，开启事务 A 的时候就生成了一个 ReadView，R

此时事务 A 第二次去查询的时候，先查到的是 trx_id = 18 的那条数据，它会发现 18 比最小的事务编号 10 大。那就说明事务编号为 18 的事务，有可能它是读不到的。

​接着就要去 m_ids 里确认是否有 18 这条数据了。发现有 18，那就说明在事务 A 开启事务的时候，这个事务是没有提交的，它修改的数据就不应该被读到。

事务 A 就会顺着 roll_pointer 指针继续往下找，找到了 trx_id = 8 这条日志，发现这条能读，读到的值任然是 x，与第一次读到的结果一致。

成功实现可重复读！