MYSQL innodb引擎下的防幻读问题

[zuoxingyu]

在MYSQL的事务引擎中，INNODB是使用范围最广的。它默认的事务隔离级别是REPEATABLE READ(可重复读），在标准的事务隔离级别定义下，REPEATABLE READ是不能防止幻读产生的。INNODB使用了2种技术手段（MVCC AND GAP LOCK)实现了防止幻读的发生。

现在的问题是，光MVCC就能够防止幻读了，为什么在加锁的时候还要使用GAP LOCK？？

[ymhctt]

我的理解mvcc只解决了非锁定度
如果没有gap lock就只能锁定读取或写入的行，如果一个事务id较小的事务插入了间隔的行，原事务再查询时，会不会就产生了幻想读呢？

[zuoxingyu]

[Quote=引用 3 楼 ymhctt 的回复:]
我的理解mvcc只解决了非锁定度
如果没有gap lock就只能锁定读取或写入的行，如果一个事务id较小的事务插入了间隔的行，原事务再查询时，会不会就产生了幻想读呢？
[/Quote]
MVCC下，INNODB只查找版本早于当前事务版本的数据行（也就是数据行的版本必须小于等于事务的版本）。
就算插入的是间隙里面，插入行的版本也比当前事务的版本要高，MVCC规则下是也是查不出来的。

[Dic4000]

请问下,gap lock应该怎么翻译比较准确?

[ymhctt]

[Quote=引用 4 楼 zuoxingyu 的回复:]
引用 3 楼 ymhctt 的回复:
我的理解mvcc只解决了非锁定度
如果没有gap lock就只能锁定读取或写入的行，如果一个事务id较小的事务插入了间隔的行，原事务再查询时，会不会就产生了幻想读呢？

MVCC下，INNODB只查找版本早于当前事务版本的数据行（也就是数据行的版本必须小于等于事务的版本）。
就算插入的是间隙里面，插入行的版本也比当前事务的版本要高，MVCC规则下是也……
[/Quote]
如果是之前未提交的事务插入的，那么该行的版本等于该事务的版本，小雨当前事务的呀

[rucypli]

单gap lock只放置了幻读，还需要mvcc来阻止未提交读

[zuoxingyu]

[Quote=引用 7 楼 rucypli 的回复:]
单gap lock只放置了幻读，还需要mvcc来阻止未提交读
[/Quote]

我也迷糊着。。。。。。。。。。
MVCC不加锁，GAP LOCK加锁。

gap lock在写的时候就锁定了间隙，幻读行是无法插入的。MVCC是在读的时候筛选某些数据，都能够防止幻读。

[zuoxingyu]

[Quote=引用 6 楼 ymhctt 的回复:]
引用 4 楼 zuoxingyu 的回复:
引用 3 楼 ymhctt 的回复:
我的理解mvcc只解决了非锁定度
如果没有gap lock就只能锁定读取或写入的行，如果一个事务id较小的事务插入了间隔的行，原事务再查询时，会不会就产生了幻想读呢？

MVCC下，INNODB只查找版本早于当前事务版本的数据行（也就是数据行的版本必须小于等于事务的版本）。
就算插入的是间隙里面，插入行的……
[/Quote]

提交后的数据行版本就大于当前的事务版本了呀。

在INSERT的时候，INNODB为每个新增行记录当前的系统版本号。

[zuoxingyu]

根据MVCC和GAP LOCK的描述，他们中的任何一个都能够做到防幻读。

[feixianxxx]

。。。。support

[zuoxingyu]

iihero大哥能够麻烦你讲解一下MVCC吗？

[iihero_]

[Quote=引用 4 楼 zuoxingyu 的回复:]

MVCC下，INNODB只查找版本早于当前事务版本的数据行（也就是数据行的版本必须小于等于事务的版本）。
就算插入的是间隙里面，插入行的版本也比当前事务的版本要高，MVCC规则下是……
[/Quote]

这一块，你的理解可能有误，
select: Its creation id must be less than or equal to the system version number. This ensures that the row was created before the current query began.
这里只是说系统版本号，应该是所有会话的最大的事务版本号

INSERT
When a row is added to a table, the database server records the current version number along with the new row, using it as the row's creation id.
这里才说是当前版本号，应该是当前会话的

还是有区别的。