这是一个创建于 3607 天前的主题，其中的信息可能已经有所发展或是发生改变。
问题一：
当事务隔离级别设置为可重复读的时候，将所有select过的行都加了读锁，并且记录了版本号，当update 的时候们如果发现版本号变了，则事务失败回滚。不知道我这样理解是否正确？
问题二：
如果上面的理解正确，那是否innodb的可重复读这个隔离级别已经帮我们实现了乐观锁，所以并不需要手动通过版本或者时间戳来实现乐观锁，或者使用 悲观锁了？
问题三：
悲观锁 select ... for update 是增加了一个写锁？ 所以所有的读写都会被block住？
问题四：
假设有事务A，先select 然后 update，事务B同样也是先select 然后再update
如果事务隔离级别为可重复读，事务A，B先后select加上了读锁，那么会不会因此而后面的update操作会互相block住，导致死锁？
问题一和问题四好像是矛盾的，因为如果问题四成立，事务会block住，也不会修改成功导致版本号不一致导致 回滚了。
当事务隔离级别设置为可重复读的时候，将所有select过的行都加了读锁，并且记录了版本号，当update 的时候们如果发现版本号变了，则事务失败回滚。不知道我这样理解是否正确？
问题二：
如果上面的理解正确，那是否innodb的可重复读这个隔离级别已经帮我们实现了乐观锁，所以并不需要手动通过版本或者时间戳来实现乐观锁，或者使用 悲观锁了？
问题三：
悲观锁 select ... for update 是增加了一个写锁？ 所以所有的读写都会被block住？
问题四：
假设有事务A，先select 然后 update，事务B同样也是先select 然后再update
如果事务隔离级别为可重复读，事务A，B先后select加上了读锁，那么会不会因此而后面的update操作会互相block住，导致死锁？
问题一和问题四好像是矛盾的，因为如果问题四成立，事务会block住，也不会修改成功导致版本号不一致导致 回滚了。
第 1 条附言 · 2014-06-24 16:14:37 +08:00
我对事务隔离理解有错，认为可重复读级别下可以避免更新丢失，实际上是错误的，参考
http://blog.163.com/wu_guoqing/blog/static/196537018201341611727602
“防止更新丢失，并不能单靠数据库事务控制器来解决，需要应用程序对要更新的数据加必要的锁来解决，因此，防止更新丢失应该是应用的责任。
“脏读”、“不可重复读”和“幻读”，其实都是数据库读一致性问题，必须由数据库提供一定的事务隔离机制来解决。数据库实现事务隔离的方式”
http://blog.163.com/wu_guoqing/blog/static/196537018201341611727602
“防止更新丢失，并不能单靠数据库事务控制器来解决，需要应用程序对要更新的数据加必要的锁来解决，因此，防止更新丢失应该是应用的责任。
“脏读”、“不可重复读”和“幻读”，其实都是数据库读一致性问题，必须由数据库提供一定的事务隔离机制来解决。数据库实现事务隔离的方式”
第 2 条附言 · 2014-06-24 16:16:35 +08:00
InnoDb的不可重复读是通过 快照实现的，不是通过读锁
 |
1
dingyaguang117 OP 经过测试，select并不会增加读锁，update之后会增加写锁，并发的另外一个事务紧接着update会发生Dead Lock 错误
|
|
2
dingyaguang117 OP 关于问题三， select 应该不会被block住
|
Select Language