怎么理解mysql特性semi consistent read
这篇文章主要讲解了“怎么理解mysql特性semi consistent read”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“怎么理解mysql特性semi consistent read”吧!
先看看官方的说法:
semi consistent read
A type of read operation used for UPDATE statements, that is a combination of read committed and consistent read. When an UPDATE statement examines a row that is already locked, InnoDB returns the latest committed version to MySQL so that MySQL can determine whether the row matches the WHERE condition of the UPDATE. If the row matches (must be updated), MySQL reads the row again, and this time InnoDB either locks it or waits for a lock on it. This type of read operation can only happen when the transaction has the read committed isolation level, or when the innodb_locks_unsafe_for_binlog option is enabled.
简单来说,semi-consistent read是read committed与consistent read两者的结合。一个update语句,如果读到一行已经加锁的记录,此时InnoDB返回记录最近提交的版本,由MySQL上层判断此版本是否满足update的where条件。若满足(需要更新),则MySQL会重新发起一次读操作,此时会读取行的最新版本(并加锁)。
semi-consistent read只会发生在read committed隔离级别或以下,或者是参数innodb_locks_unsafe_for_binlog被设置为true。
semi consistent read作用情形:
1、RC、RU模式下,或者 innodb_locks_unsafe_for_binlog = 1
2、先执行非UPDATE SQL,后执行UPDATE,不会阻塞。如果先执行UPDATE,后执行其他非UPDATE SQL,则还是会加锁
3、只影响有实际存在的行,不存在的行也OK
我的理解:
在rc级别或以下级别(ru),或者 innodb_locks_unsafe_for_binlog = 1(RR) 这三种情况下,会发生semi_consistent_read.
因为innodb是行级锁,如果字段没有索引,在加锁时,会上升为表锁.此时,如果s1执行加锁任何操作,s2执行update操作,在s2的update条件中如果在s1中没有行锁,将不会堵塞s2.原理是:s2发起的update,有mysql上层根据update条件判断是否满足,若条件中没有行锁,则mysql会重新发起一次读操作,并在update后加锁;
同理:如果列是有索引存在的.innodb会自动产生的是行锁,所以semi_consistent_read的效能也就没有什么意义..
所以.semi_consistent_read只发生在没有索引的列,或者有全表锁的情况;只要存在update的数据上有行锁的,semi_consistent_read就失效;
感谢各位的阅读,以上就是“怎么理解mysql特性semi consistent read”的内容了,经过本文的学习后,相信大家对怎么理解mysql特性semi consistent read这一问题有了更深刻的体会,具体使用情况还需要大家实践验证。这里是亿速云,小编将为大家推送更多相关知识点的文章,欢迎关注!
免责声明:
① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。
② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341