MySQL是如何解决幻读问题的？( 二 ) _小知识

m_ids：生成read view 时候，活跃的事物id集合
min_trx_id：m_ids的最小值，既生成read view的时候，活跃事物的最小值
max_trx_id：表示生成read view的时候，系统应该分配下一个事物id值
creator_trx_id：创建read view的事物id，即当前事物id 。

有了这个ReadView，这样在访问某条记录时，只需要按照下边的步骤判断记录的某个版本是否可见：

文章插图

当记录的事物id等于creator_trx_id的时候，说明当前事物正在访问自己修改的记录，所以该版本可见
如果被访问的版本事物id小于min_trx_id的时候，则说明，在创建read view的时候，该事物已经提交，该版本，对当前事物可读
如果被访问的版本事物id大于或等于max_trx_id，则说明创建该read view的时候，该说明生成该版本记录的事物id在生成Read view之后才开启，所以该版本不能被当前事物可读
如果被访问的版本事物transaction_id在m_ids集合中，说明生成Read view的时候，该事物还是活跃的，还没有被提交，则该版本不可以被访问；如果不在，则说明创建ReadView时生成该版本的事务已经被提交，可以被访问

注：读事物的事物id为0
在MySQL中，READ COMMITTED和REPEATABLE READ隔离级别的的一个非常大的区别就是它们生成ReadView的时机不同:

READ COMMITTED —— 每次读取数据前都生成一个ReadView
REPEATABLE READ —— 在第一次读取数据时生成一个ReadView

下面我们通过详细例子来说明，两者有何不同：
时间编号

trx 100
trx 200
①
BEGIN;

②

BEGIN;
BEGIN;
③

update person set grade =20 where id =1;

④

update person set grade =40 where id =1;

⑤
SELECT * FROM person WHERE id = 1;

⑥

COMMIT;

⑦

update person set grade =70 where id =1;
⑧
SELECT * FROM person WHERE id = 1;

⑨

COMMIT;

COMMIT;

在时间④中，因事务trx 100 执行了事务的提交，id=1行记录的版本链如下：

文章插图

在时间⑥中，因事务trx 200 执行了事务的提交，id=1行记录的版本链如下：

文章插图

在时间⑤，事务trx 100执行select语句时会先生成一个ReadView，ReadView的m_ids列表的内容就是[100, 200]，min_trx_id为100，max_trx_id为201，creator_trx_id为0，此时，从版本链中选可见的记录，版本链从上到下遍历：因为grade=40，trx_id值为100，在m_ids里，所以该记录不可见，同理，grade=20的也不见。继续往下遍历，grade=20,trx_id值为80,小于小于ReadView中的min_trx_id值100，所以这个版本符合要求，返回给用户的是等级为10的记录。
在时间⑧中，如果事务的隔离级别是READ COMMITTED，会单独又生成一个ReadView，该ReadView的m_ids列表的内容就是[200]，min_trx_id为200，max_trx_id为201，creator_trx_id为0，此时，从版本链中选可见的记录，版本链从上到下遍历：因为grade=70，trx_id值为200，在m_ids里，所以该记录不可见，继续往下遍历，grade=40,trx_id值为100，小于ReadView中的min_trx_id值200，所以这个版本是符合要求的，返回给用户的是是等级为40的记录。
在时间⑧中，如果事务的隔离级别是 REPEATABLE READ，在时间⑧中，不会单独生成一个ReadView，而是沿用时间5的ReadView，所以返回给用户的等级是10 。前后两次select得到的是一样的，这就是可重复读的含义。
3. 总结通过分析MVCC详解部分，可以得出，基于MVCC，在RR隔离级别下，很好解决了幻读问题，但是我们知道，select for update是产生当前读，不再是快照读，那么此种情况，MySQL又是怎么解决幻读问题的呢？基于时间问题(整理画图的确需要花比较多的时间)，此处先给结论，后面再分析在当前读的情况下，MySQL是怎么解决幻读问题：