大家好，又见面了，我是你们的朋友全栈君。如果您正在找激活码,请点击查看最新教程,关注关注公众号 “全栈程序员社区” 获取激活教程,可能之前旧版本教程已经失效.最新Idea2022.1教程亲测有效,一键激活。
Jetbrains全系列IDE使用 1年只要46元 售后保障 童叟无欺
今天同事问Oracle里的一致读也会像MySQL默认的锁住扫描的行吗？
首先要明确Oracle里支持的隔离级别：read committed/serializable,默认的是read committed，而MySQl支持的隔离级别：read uncommitted/read committed/repeatable read/serializable，默认的是repeatable read;
先说结论：Oracle的read committed的锁力度和隔离级别相当于MySQL的read committed，因此Oracle里默认的一致读对
测试锁力度
Oracle read committed：
SQL> createtable t(id primary key ,value ) as select rownum,mod(rownum,100) fromdba_objects /
Table created.
Oracle：
Session：3401
select * from twhere value=55 for update
Session：7
select * from twhere value=56 for update
无阻塞；
Session 3401不提交，Session 7执行select * from t wherevalue=55 for update时发生阻塞：
MySQL repeatable read：
Session 1：
mysql> select* from t where value=55 for update;
Session 2：
mysql> select* from t where value=56 for update;
从information_schema里可以看到阻塞：
那么为什么MySQL默认的隔离级别是repeatable read呢？其实这是个历史原因：在MySQL5.0时，binlog_format只支持Statement，如果设置隔离级别为read committed会导致主从不一致，简例如下：
mysql> select * from t;
+——+
| id |
+——+
| 1|
| 2|
| 4|
| 5|
+——+
Session1 onmaster:
Begin;
Delete from twhere id<=5;
Session2 onmaster:
Insert into tvalues(3);
Commit;
Session 1 onmaster:
Commit;
此时Master的t中有一行记录3，而Slave的t为空，造成不一致；如果是repeatable read则session2的insert会被gap lock住；
在MySQL5.1之后binlog支持ROW模式，在该模式下使用read committed上述情况则不成立；
本文转自MIKE老毕 51CTO博客，原文链接：http://blog.51cto.com/boylook/1307762，如需转载请自行联系原作者
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/194850.html原文链接：https://javaforall.net
