不可重复读:事务A多次读取同一个数据,事务B在事务A多次读取的过程中,对数据作了更新,导致事务A多次读取同一个数据时,结果不一致。(比如修改行数据)
幻读:事务A 按照一定条件进行数据读取, 期间事务B 插入了相同搜索条件的新数据,事务A再次按照原先条件进行读取时,发现了事务B 新插入的数据 称为幻读。(比如查询表中数据记录数)
浅解释
概念
1、InnoDB 在每行记录后面保存两个隐藏的列,分别保存了数据行的创建版本号和删除版本号。每开始一个新的事务,系统版本号都会递增。事务开始时刻的系统版本号会作为事务的版本号,用来和查询到的每行记录的创建版本号对比。
2、insert:为插入的每一行保存当前系统版本号作为创建版本号。
3、delete:为删除的每一行保存当前系统版本号作为删除版本号。
4、update:插入一条新数据,保存当前系统版本号作为创建版本号。同时保存当前系统版本号作为原来的数据行删除版本号。
演示
事务A插入一条数据,假设当前系统版本号为1
insert into user (id,name) values (1,'Tom');
得到这条数据
id nanme create_version delete_version
1 Tom 1
事务A查询数据---根据事务A版本号
select * from user where id = 1;
得到这条数据
id nanme create_version delete_version
1 Tom 1
事务B修改数据,事务B版本号为2
update user set name = 'Jerry' where id = 1;
提交后
id nanme create_version delete_version
1 Tom 1 2
1 Jerry 2
事务A查询数据---根据事务A版本号
select * from user where id = 1;
id nanme create_version delete_version
1 Tom 1 2
**得出结论:可重复读并不会发生不可重复读**
事务C删除数据
delete from user where id = 1;
id nanme create_version delete_version
1 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,与第一次读到的结果一致。
成功实现可重复读!