Oralce/MySQL 默认隔离级别对比

今天同事问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时发生阻塞：

<a href="http://blog.51cto.com/attachment/201310/004922909.png" target="_blank"></a>

MySQL repeatable read：

Session 1：

mysql&gt; select* from t where value=55 for update;

Session 2：

mysql&gt; select* from t where value=56 for update;

从information_schema里可以看到阻塞：

<a href="http://blog.51cto.com/attachment/201310/004922298.png" target="_blank"></a>

<a href="http://blog.51cto.com/attachment/201310/004922295.png" target="_blank"></a>

那么为什么MySQL默认的隔离级别是repeatable read呢？其实这是个历史原因：在MySQL5.0时，binlog_format只支持Statement，如果设置隔离级别为read committed会导致主从不一致，简例如下：

mysql&gt; select * from t;

+------+

| id |

| 1|

| 2|

| 4|

| 5|

Session1 onmaster:

Begin;

Delete from twhere id&lt;=5;

Session2 onmaster:

Insert into tvalues(3);

Commit;

Session 1 onmaster:

此时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，如需转载请自行联系原作者