mysql 的不可重复读/幻度 是哪种方式解决的？

[Golden_Dog]

在看《MySql技术内幕 InnoDB存储引擎》中关于 不可重复读/幻度有个奇怪的问题：

一致性的非锁定读可以解决 不可重复读和幻读问题
然后书上又提到 Next-Key Lock算法解决了 不可重复读和幻读。
那么到底是哪个技术解决了不可重复都和幻读问题呢？

++++++++++++++以下个人理解++++++++++++++++
在Repeatable Read模式下，测试来看：
select....from..... 会采用一致性的非锁定读，不会阻塞另一个会话同一个表的DML操作
select.....from....for update 会采用 Next-Key Lock，会阻塞另一个会话同一个表的DML操作

在个人看来Next-Key Lock是用来锁整个表的，不能有并发表操作，天然的避免了不可重复读和幻读。
而一致性非锁定读可以做到DML操作期间读取记录，可以与DML操作并发，同样避免了不可重复度和幻度。

[zjcxc]

在Repeatable Read模式下，测试来看： select....from..... 会采用一致性的非锁定读，不会阻塞另一个会话同一个表的DML操作 ------------------------- 它读的是快照，在读取的事务期间，这个快照是维持的，所以解决了不可重复读和幻读 的疸，如果没有快照的支持，就需要锁来支持了

[zjcxc]

参考官网文档 https://dev.mysql.com/doc/refman/5.7/en/innodb-transaction-isolation-levels.html REPEATABLE READ This is the default isolation level for InnoDB. Consistent reads within the same transaction read the snapshot established by the first read. This means that if you issue several plain (nonlocking) SELECT statements within the same transaction, these SELECT statements are consistent also with respect to each other

[Golden_Dog]

引用 1 楼 zjcxc 的回复:

在Repeatable Read模式下，测试来看： select....from..... 会采用一致性的非锁定读，不会阻塞另一个会话同一个表的DML操作 ------------------------- 它读的是快照，在读取的事务期间，这个快照是维持的，所以解决了不可重复读和幻读 的疸，如果没有快照的支持，就需要锁来支持了

ok，那你的意思是两种方式都可以解决不可重复读和幻度？而快照这东西并不是所有的Record都会有一份，当某个Record没有快照的时候就需要使用锁了是吧？ 那么，select....from.....什么情况下会出现没有快照呢？没有快照时，是不是处于Repeatable Read中的select....from....就会相当于一个select....from....for update呢？

[zjcxc]

参考官网文档 https://dev.mysql.com/doc/refman/5.7/en/innodb-transaction-isolation-levels.html REPEATABLE READ This is the default isolation level for InnoDB. Consistent reads within the same transaction read the snapshot established by the first read. This means that if you issue several plain (nonlocking) SELECT statements within the same transaction, these SELECT statements are consistent also with respect to each other

[Golden_Dog]

引用 1 楼 zjcxc 的回复:

在Repeatable Read模式下，测试来看： select....from..... 会采用一致性的非锁定读，不会阻塞另一个会话同一个表的DML操作 ------------------------- 它读的是快照，在读取的事务期间，这个快照是维持的，所以解决了不可重复读和幻读 的疸，如果没有快照的支持，就需要锁来支持了

ok，那你的意思是两种方式都可以解决不可重复读和幻度？而快照这东西并不是所有的Record都会有一份，当某个Record没有快照的时候就需要使用锁了是吧？ 那么，select....from.....什么情况下会出现没有快照呢？没有快照时，是不是处于Repeatable Read中的select....from....就会相当于一个select....from....for update呢？

[Golden_Dog]

引用 3 楼 zjcxc 的回复:

参考官网文档 https://dev.mysql.com/doc/refman/5.7/en/innodb-transaction-isolation-levels.html REPEATABLE READ This is the default isolation level for InnoDB. Consistent reads within the same transaction read the snapshot established by the first read. This means that if you issue several plain (nonlocking) SELECT statements within the same transaction, these SELECT statements are consistent also with respect to each other

ok，看下来，所以快照是第一个select 操作生成的，其后同一个transaction中的select操作会与采用快照技术与第一个select操作结果一致。 这也就是为什么mysql 的Innondb的Repeatable Read下，能够保证 不可重复读/幻读 的方式。 这就又回到开始的问题，到底是快照技术还是锁 来解决的 不可重复读/幻读 问题呢？

[zjcxc]

两种都是实现手段，FOR UPDATE 是手工控制了，无视事务隔离级别 如果你不使用加锁选项 FOR UPDATE (或 LOCK IN SHARE MODE），则是数据库的自动行为，处理的方式取决于事务隔离级别，在 Repeatable Read 级别解决了不可重复读和幻度 而且官网文档也说明了，用的快照，不是加锁，所以它并不等同于 FOR UPDATE，后者是加锁，其他操作无法更新，也无法再 SELECT FOR UPDATE 的，因为这些资源已经有锁，而前者没问题，因为这些资源上没锁

[zjcxc]

所以不是谁解决问题，是你具体用的时候是什么情景在用

[Golden_Dog]

引用 8 楼 zjcxc 的回复:

所以不是谁解决问题，是你具体用的时候是什么情景在用

OK,基本明白了。 我这边做了一些测试，总结是这样： 在Rereatable Read下： select....from会采用快照，读取的是事务开始的快照，保证了不可重复读和幻读 select .....from .... for update会采用 Next-Key Locking来保证不可重复读和幻读 在Committed Read下: select....from 会采用快照，读取的是最新一份的快照数据，不能够保证不可重复读和幻读 select .....from .... for update会采用Record Lock，不能够保证不可重复读/幻度问题 所以，一开始我是有点弄混了，其实完全是对两种select来说的。

[cjs5202001]

四种隔离级别，参考：http://blog.daozys.com/goods_89.html