即:
即 快照读 的问题在于:在同一个事务中,能够读取到之前提交的数据。表现为:
字面意思:在事务中,为查询创建的快照,并不适用与 DML 语句。
也就是说:如果事务 A 开始时创建的快照,查询不到数据 col1=1 ,但此时事务 B 刚刚提交 insert col1=1 和 insert col1=1 ,此时如果事务 A 执行, delete col1=1 ,是能将事务 B 生成的数据删除的。
字面意思:即使事务 A 的快照是在事务 B 提交之前创建的,但事务 A 也只有在事务 A 和事务 B 都提交后,才能看到事务 B 新增的数据。
首先我们做一个模拟,执行以下的sql,其中有如下图数据:
我把执行结果按照表格如下展示:
分析:
在会话1当中,只有当会话1的事务提交后,才能查到最终会话2更改的数据。
在会话2当中,开启事务后更新数据,之后查询发现数据变成了17。
针对上面的现象我们进行个原理分析:
实际上产生上述显现是因为InnoDB采用的MVCC(多版本并发控制),其中针对每条数据会有它自己的事务id,以及一个最大事务id。针对事务中数据每次修改,会产生不同的版本。
1)假设开始id = 2的数据,其事务txid = 1000;
2)当会话1开始,此时txid变成了1001,而会话2开启,txid又变成了1002,同理会话3会变成1003,此时都生成了不同版本的快照。
3)会话1在事务当中去读取时候,采用了快照读的方式,即拿到一个1001的事务id,此时只会读取小于等于自己版本的数据,所以在事务中最终只能拿到值为17的数据。
4)会话2在更新数据的时候,采用的当前读的方式,即对数据增加X锁,获取最新的事务id,读取最新的版本数据。所以在更新之前,就读取到了age的年龄是16,之后在进行+1,得到17.
总结一下:
快照读 解决了幻读的问题,即多次读取数据不一致的问题。
update、insert、delete都会执行 当前读 ,防止并发更新数据导致数据错误,此过程或添加X锁。
一、定义1、幻读MYSQL官方叫法是Phantom Rows,意为鬼影行或者幻影行,请看官方定义:
The so-called phantom problem occurs within a transaction when the same query produces different sets of rows at different times. For example, if a [ SELECT ] is executed twice, but returns a row the second time that was not returned the first time, the row is a “phantom” row.
翻译一下:
所谓的幻影行问题是指,在同一个事务中,同样的查询语句执行多次,得到了不同的行结果集。
例如,如果同一个SELECT语句执行了两次,第二次执行的时候比第一次执行时多出一行,则该行就是所谓的幻影行。
2、幻读与不可重复读的区别
从官方的定义来看,幻读的定义侧重于多条记录,就是记录条数的变化,而不可重复读侧重于单条记录数据的变化,这样区分原因在于解决幻读需要范围锁,解决不可重复读只需要单条记录加锁
二、InnoDB的REPEATABLE READ级别
InnoDB支持由SQL1992标准描述的所有四个事务隔离级别,默认隔离级别是 REPEATABLE READ。
1、快照读:
在RR模式下,第一次读取会建立快照,后续查询会读取快照。
这意味着,如果在同一事务中发出多个普通[ SELECT ](非锁定)语句,则这些 [ SELECT ]语句的结果也是一致的。
2、[locking reads](锁定读取,又叫当前读)
[ SELECT ]语句中使用 FOR UPDATE 或 FOR SHARE
3、行锁
在RR模式下,使用当前读以及 [ UPDATE ]和 [ DELETE ]语句会对数据记录加行锁,锁定范围取决于该语句使用的是具有唯一搜索条件的唯一索引还是范围类型搜索条件。
三、InnoDB的READ COMMITTED级别
1、在RC模式下,每次读取都会刷新快照,因此不能保证可重复读
2、在RC模式下,使用当前读以及 [ UPDATE ]和 [ DELETE ]语句会对数据记录加行锁,但是不会加范围锁,间隙锁定仅用于外键约束检查和重复键检查。
3、由于禁用了间隙锁定,因此可能会产生幻影行问题,因为其他会话可以在间隙中插入新行。
4、 对于[ UPDATE ]或 [ DELETE ]语句, InnoDB 仅对其更新或删除的行持有锁。MySQL评估 WHERE 条件后,将释放不匹配行的记录锁 。这大大降低了死锁的可能性,但是仍然可以发生。
5、对于[ UPDATE ]语句,如果某行已被锁定,则 InnoDB 执行“半一致”读取,将最新提交版本的数据返回给MySQL,以便MySQL可以确定该行是否符合 WHERE 条件。如果该行匹配(必须更新),则MySQL会再次读取该行,这一次 InnoDB 会将其锁定或等待获取锁。
6、注意
从MySQL 8.0.22开始,DML *** 作(增删改,通过联接列表或子查询)从MySQL授权表中读取数据,但不对其进行修改,无论隔离级别如何,都不会在MySQL授权表上获得读取锁。
有关更多信息,请参见 Grant Table Concurrency 。
四、乐观锁与悲观锁
1、乐观锁
在UPDATE的WHERE子句中加入版本信息来确定修改是否生效
使用乐观锁时仍然需要非常谨慎,因为RR是可重复读的,在UPDATE之前读取版本号,应该使用[当前读],不能使用[快照读]
2、悲观锁
在UPDATE执行前,SELECT后面加上FOR UPDATE来给记录加锁,保证记录在UPDATE前不被修改。SELECT ... FOR UPDATE是加上了X锁,也可以通过SELECT ... LOCK IN SHARE MODE加上S锁,来防止其他事务对该行的修改。
3、无论是乐观锁还是悲观锁,使用的思想都是一致的,那就是当前读。乐观锁利用当前读判断是否是最新版本,悲观锁利用当前读锁定行。
五、总结
1、RC级别没有范围锁一定会导致不可重复读和幻影行
2、RR级别安全性更高,实现可重复读的方式为快照,如果需要最新数据可以选择[当前读],因此RR级别是首选
3、不论RR还是RC级别,增、删、改的 *** 作都会进行一次[当前读] *** 作,以此获取最新版本的数据,并检测是否有重复的索引。
4、RR级别下,当前事务如果未发生更新 *** 作(增删改),快照版本会保持不变,多次查询读取的快照是同一个
5、RR级别下,当前事务如果发生更新(增删改),会刷新快照,会导致不可重复读和幻影行
6、RR级别下,使用当前读,会刷新快照,会导致不可重复读和幻影行
7、RR级别下,可以通过提交当前事务并在此之后发出新查询来为查询获取更新的快照。
8、RR级别可以部分解决不可重复读和幻读问题
9、其实问题的关键是你的业务逻辑需要可重复读还是最新数据
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)