MySQL45讲之幻读 – flowers

MySQL45讲之幻读 – flowers本文介绍什么是幻读,幻读存在的问题和解决方式,以及间隙锁带来的困扰。

MySQL45讲之幻读 - flowers

前言

本文介绍什么是幻读,幻读存在的问题和解决方式,以及间隙锁带来的困扰。

什么是幻读

什么是幻读,有两个条件:

  1. 必须是“当前读”情况下才可能发生,“快照读”不会出现
  2. 只有插入操作才算幻读,更新和删除不算

幻读的问题

幻读会造成哪些问题?主要有两点:

  1. 在同一个事务内执行的两次或多次“当前读”操作,结果不一致
  2. 数据和日志记录不一致

模拟幻读

执行上述事务操作后,binlog 记录如下:

insert into t values(1,1,5); /*(1,1,5)*/
update t set c=5 where id=1; /*(1,5,5)*/

update t set d=100 where d=5;/*所有d=5的行,d改成100*/

update t set d=5 where id=0; /*(0,0,5)*/
update t set c=5 where id=0; /*(0,5,5)*/

执行的结果 id=1 这行是 (1,5,5),而 binlog 日志记录的是 (1,5,100),可见数据和日志是不一致的。

如何解决幻读

MySQL 在行锁(Record Lock)的基础之上,又引入了间隙锁(Gap Lock)。间隙锁就是对两条记录之间的间隙上锁,避免幻读在已经上锁情况下插入记录。注意,间隙锁之间不是互斥的。

行锁和间隙锁的结合称之为 next-key 锁,是一个前开后闭的区间,比如 (-∞,0]、(0,5]、(5,10]、(10,+suprenum]。其中,suprenum 是 InnoDB 为每个索引添加的不存在的最大值。

间隙锁的困扰

间隙锁解决了幻读的问题,但也带来了事务并发度降低和死锁的问题。比如下面的业务逻辑:

begin;
select * from t where id=N for update;

/*如果行不存在*/
insert into t values(N,N,N);
/*如果行存在*/
update t set d=N set id=N;

commit;

为什么会产生死锁呢?看下面的事务流程:

间隙锁造成死锁

session A 和 session B 都对 (5,10) 间隙上锁,之后判断记录不存在,A 和 B 都进行记录插入操作,然后因为对方对 (5,10) 间隙上锁,导致锁等待,进入死锁状态。MySQL 检测到死锁后,重启 session A 事务,让 session B 先执行成功。

那有没有简单的方法避免这个死锁问题呢?
可以考虑将事务隔离级别设置为“提交读”,避免间隙锁同时提高事务的并发度。但是为了解决数据和日志的不一致问题,还需要将 binlog 格式设置为 row 模式。

参考

  • [1] 幻读是什么,幻读有什么问题

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
转载请注明出处: https://daima100.com/5836.html

(0)
上一篇 2023-04-22
下一篇 2023-04-22

相关推荐

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注