MySQL 中隔离级别 RC 与 RR 的区别

共计 8273 个字符，预计需要花费 21 分钟才能阅读完成。

1. 数据库事务 ACID 特性

数据库事务的 4 个特性：
原子性 (Atomic): 事务中的多个操作，不可分割，要么都成功，要么都失败；All or Nothing.
一致性 (Consistency): 事务操作之后, 数据库所处的状态和业务规则是一致的; 比如 a,b 账户相互转账之后，总金额不变；
隔离性 (Isolation): 多个事务之间就像是串行执行一样，不相互影响;
持久性 (Durability): 事务提交后被持久化到永久存储.

2. 隔离性

其中 隔离性 分为了四种：

READ UNCOMMITTED：可以读取未提交的数据，未提交的数据称为脏数据，所以又称脏读。此时：幻读，不可重复读和脏读均允许；
READ COMMITTED：只能读取已经提交的数据；此时：允许幻读和不可重复读，但不允许脏读，所以 RC 隔离级别要求解决脏读；
REPEATABLE READ：同一个事务中多次执行同一个 select, 读取到的数据没有发生改变；此时：允许幻读，但不允许不可重复读和脏读，所以 RR 隔离级别要求解决不可重复读；
SERIALIZABLE: 幻读，不可重复读和脏读都不允许，所以 serializable 要求解决幻读；

3. 几个概念

脏读：可以读取未提交的数据。RC 要求解决脏读；

不可重复读：同一个事务中多次执行同一个 select, 读取到的数据发生了改变(被其它事务 update 并且提交)；

可重复读：同一个事务中多次执行同一个 select, 读取到的数据没有发生改变(一般使用 MVCC 实现)；RR 各级级别要求达到可重复读的标准；

幻读：同一个事务中多次执行同一个 select, 读取到的数据行发生改变。也就是行数减少或者增加了(被其它事务 delete/insert 并且提交)。SERIALIZABLE 要求解决幻读问题；

这里一定要区分不可重复读和幻读：

不可重复读的重点是修改 :
同样的条件的 select, 你读取过的数据, 再次读取出来发现值不一样了

幻读的重点在于 新增或者删除 :
同样的条件的 select, 第 1 次和第 2 次读出来的记录数不一样

从结果上来看, 两者都是为多次读取的结果不一致。但如果你从实现的角度来看, 它们的区别就比较大：
对于前者, 在 RC 下只需要锁住满足条件的记录，就可以避免被其它事务修改，也就是 select for update, select in share mode; RR 隔离下使用 MVCC 实现可重复读；
对于后者, 要锁住满足条件的记录及所有这些记录之间的 gap，也就是需要 gap lock。

而 ANSI SQL 标准没有从隔离程度进行定义，而是定义了事务的隔离级别，同时定义了不同事务隔离级别解决的三大并发问题：

*Isolation Level*	Dirty Read	Unrepeatable Read	Phantom Read
Read UNCOMMITTED	YES	YES	YES
READ COMMITTED	NO	YES	YES
READ REPEATABLE	NO	NO	YES
SERIALIZABLE	NO	NO	NO

参见：你真的明白事务的隔离性吗？(姜承尧)

4. 数据库的默认隔离级别

除了 MySQL 默认采用 RR 隔离级别之外，其它几大数据库都是采用 RC 隔离级别。

但是他们的实现也是极其不一样的。Oracle 仅仅实现了 RC 和 SERIALIZABLE 隔离级别。默认采用 RC 隔离级别，解决了脏读。但是允许不可重复读和幻读。其 SERIALIZABLE 则解决了脏读、不可重复读、幻读。

MySQL 的实现：MySQL 默认采用 RR 隔离级别，SQL 标准是要求 RR 解决不可重复读的问题，但是因为 MySQL 采用了 gap lock，所以实际上 MySQL 的 RR 隔离级别也解决了幻读的问题。那么 MySQL 的 SERIALIZABLE 是怎么回事呢？其实 MySQL 的 SERIALIZABLE 采用了经典的实现方式，对读和写都加锁。

5. MySQL 中 RC 和 RR 隔离级别的区别

MySQL 数据库中默认隔离级别为 RR，但是实际情况是使用 RC 和 RR 隔离级别的都不少。好像淘宝、网易都是使用的 RC 隔离级别。那么在 MySQL 中 RC 和 RR 有什么区别呢？我们该如何选择呢？为什么 MySQL 将 RR 作为默认的隔离级别呢？

5.1 RC 与 RR 在锁方面的区别

1> 显然 RR 支持 gap lock(next-key lock)，而 RC 则没有 gap lock。因为 MySQL 的 RR 需要 gap lock 来解决幻读问题。而 RC 隔离级别则是允许存在不可重复读和幻读的。所以 RC 的并发一般要好于 RR；

2> RC 隔离级别，通过 where 条件过滤之后，不符合条件的记录上的行锁，会释放掉(虽然这里破坏了“两阶段加锁原则”)；但是 RR 隔离级别，即使不符合 where 条件的记录，也不会是否行锁和 gap lock；所以从锁方面来看，RC 的并发应该要好于 RR；另外 insert into t select … from s where 语句在 s 表上的锁也是不一样的，参见下面的例子 2；

例子 1：

MySQL5.6, 隔离级别 RR，autocommit=off;

表结构：

mysql> show create table t1\G
*************************** 1. row ***************************
       Table: t1
Create Table: CREATE TABLE `t1` (`a` int(11) NOT NULL,
  `b` int(11) NOT NULL,
  `c` int(11) NOT NULL,
  `d` int(11) NOT NULL,
  `e` varchar(20) DEFAULT NULL,
  PRIMARY KEY (`a`),
  KEY `idx_t1_bcd` (`b`,`c`,`d`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
1 row in set (0.00 sec)

表数据：

mysql> select * from t1;
+---+---+---+---+------+
| a | b | c | d | e    |
+---+---+---+---+------+
| 1 | 1 | 1 | 1 | a    |
| 2 | 2 | 2 | 2 | b    |
| 3 | 3 | 2 | 2 | c    |
| 4 | 3 | 1 | 1 | d    |
| 5 | 2 | 3 | 5 | e    |
| 6 | 6 | 4 | 4 | f    |
| 7 | 4 | 5 | 5 | g    |
| 8 | 8 | 8 | 8 | h    |
+---+---+---+---+------+
8 rows in set (0.00 sec)

操作过程：
session 1:

delete from t1 where b>2 and b<5 and c=2;

执行计划如下：

mysql> explain select * from t1 where b>2 and b<5 and c=2\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: t1
         type: range
possible_keys: idx_t1_bcd
          key: idx_t1_bcd
      key_len: 4
          ref: NULL
         rows: 2
        Extra: Using index condition
1 row in set (0.00 sec)

session 2:

delete from t1 where a=4

结果 session 2 被锁住。
session 3:

mysql> select * from information_schema.innodb_locks;
+---------------+-------------+-----------+-----------+-------------+------------+------------+-----------+----------+-----------+
| lock_id       | lock_trx_id | lock_mode | lock_type | lock_table  | lock_index | lock_space | lock_page | lock_rec | lock_data |
+---------------+-------------+-----------+-----------+-------------+------------+------------+-----------+----------+-----------+
| 38777:390:3:5 | 38777       | X         | RECORD    | `test`.`t1` | PRIMARY    |        390 |         3 |        5 | 4         |
| 38771:390:3:5 | 38771       | X         | RECORD    | `test`.`t1` | PRIMARY    |        390 |         3 |        5 | 4         |
+---------------+-------------+-----------+-----------+-------------+------------+------------+-----------+----------+-----------+

根据锁及 ICP 的知识，此时加锁的情况应该是在索引 idx_t1_bcd 上的 b >2 and b<5 之间加 gap lock, idx_t1_bcd 上的 c =2 加 X 锁主键 a=3 加 x 锁。
应该 a = 4 上是没有加 X 锁的，可以进行删除与更改。
但是从 session3 上的结果来，此时 a = 4 上被加上了 X 锁。
求大牛解惑，谢谢。

——-

要理解这里为什么 a=4 被锁住了，需要理解 gap lock，锁处理 RR 隔离级别和 RC 隔离级别的区别等等。

这里的原因如下：

很简单，我们注意到：key_len: 4 和 Extra: Using index condition
这说明了，仅仅使用了索引 idx_t1_bcd 中的 b 一列，没有使用到 c 这一列。c 这一列是在 ICP 时进行过滤的。所以：

delete from t1 where b>2 and b<5 and c=2 其实锁定的行有：

mysql> select * from t1 where b>2 and b<=6;
+---+---+---+---+------+
| a | b | c | d | e    |
+---+---+---+---+------+
| 3 | 3 | 2 | 2 | c    |
| 4 | 3 | 1 | 1 | d    |
| 6 | 6 | 4 | 4 | f    |
| 7 | 4 | 5 | 5 | g    |
+---+---+---+---+------+
4 rows in set (0.00 sec)

所以显然 delete from t1 where a=4 就被阻塞了。那么为什么 delete from t1 where a=6 也会被阻塞呢？？？

这里 b<=6 的原因是，b 列中没有等于 5 的记录，所以 and b<5 实现为锁定 b<=6 的所有索引记录，这里有等于号的原因是，如果我们不锁定 =6 的索引记录，那么怎么实现锁定 <5 的 gap 呢？也就是说锁定 b=6 的索引记录，是为了实现锁定 b< 5 的 gap。也就是不能删除 b=6 记录的原因 。
而这里 b >2 没有加等于号 (b>=2) 的原因， 是因为 b>2 的这个 gap 是由 b= 3 这个索引记录 (的 gap) 来实现的 ，不是由 b= 2 索引记录(的 gap) 来实现的，b= 2 的索引记录的 gap lock 只能实现锁定 <2 的 gap，b>2 的 gap 锁定功能，需要由 b= 3 的索引记录对应的 gap 来实现(b>2，b<3 的 gap)。
所以我们在 session2 中可以删除：a=1,2,5,8 的记录，但是不能删除 a=6(因为该行的 b =6)的记录。

如果我们使用 RC 隔离级别时，则不会发生阻塞，其原因就是：

RC 和 RR 隔离级别中的锁处理不一样，RC 隔离级别时，在使用 c 列进行 ICP where 条件过滤时，对于不符合条件的记录，锁会释放掉，而 RR 隔离级别时，即使不符合条件的记录，锁也不会释放(虽然违反了“2 阶段锁”原则)。所以 RC 隔离级别时 session 2 不会被阻塞。

Gap lock: This is a lock on a gap between index records, or a lock on the gap before the first or after the last index record.

例子 2：insert into t select … from s where 在 RC 和 RR 隔离级别下的加锁过程

下面是官方文档中的说明：http://dev.mysql.com/doc/refman/5.6/en/innodb-locks-set.html

INSERT INTO T SELECT … FROM S WHERE … sets an exclusive index record lock (without a gap lock) on each row inserted into T. If the transaction isolation level is READ COMMITTED, or innodb_locks_unsafe_for_binlog is enabled and the transaction isolation level is not SERIALIZABLE, InnoDB does the search on S as a consistent read (no locks). Otherwise, InnoDB sets shared next-key locks on rows from S. InnoDB has to set locks in the latter case: In roll-forward recovery from a backup, every SQL statement must be executed in exactly the same way it was done originally.

CREATE TABLE … SELECT … performs the SELECT with shared next-key locks or as a consistent read, as for INSERT … SELECT.

When a SELECT is used in the constructs REPLACE INTO t SELECT … FROM s WHERE … or UPDATE t … WHERE col IN (SELECT … FROM s …), InnoDB sets shared next-key locks on rows from table s.

insert inot t select … from s where … 语句和 create table … select … from s where 加锁过程是相似的(RC 和 RR 加锁不一样)：

1> RC 隔离级别时和 RR 隔离级别但是设置innodb_locks_unsafe_for_binlog=1 时，select … from s where 对 s 表进行的是一致性读，所以是无需加锁的；

2> 如果是 RR 隔离级别(默认innodb_locks_unsafe_for_binlog=0)，或者是 serializable 隔离级别，那么对 s 表上的每一行都要加上 shared next-key lock.

这个区别是一个很大的不同，下面是生成中的一个 insert into t select … from s where 导致的系统宕机的案例：

一程序猿执行一个分表操作：

insert into tb_async_src_acct_201508 select * from tb_async_src_acct 

where src_status=3 and create_time>='2015-08-01 00:00:00' and create_time <= '2015-08-31 23:59:59';

表 tb_async_src_acct 有 4000W 数据。分表的目的是想提升下性能。结果一执行该语句，该条 SQL 被卡住，然后所有向 tb_async_src_acct 的写操作，要么是 get lock fail, 要么是 lost connection，全部卡住，然后主库就宕机了。

显然这里的原因，就是不知道 默认 RR 隔离级别中 insert into t select … from s where 语句的在 s 表上的加锁过程，该语句一执行，所有符合 where 条件的 s 表中的行记录都会加上 shared next-key lock(如果没有使用到索引，还会锁住表中所有行)，在整个事务过程中一直持有，因为表 tb_async_src_acct 数据很多，所以运行过程是很长的，所以加锁过程也是很长，所以其它所有的对 tb_async_src_acct 的 insert, delete, update, DDL 都会被阻塞掉，这样被阻塞的事务就越来越多，而事务也会申请其它的表中的行锁，结果就是系统中被卡住的事务越来越多，系统自然就宕机了。

5.2 RC 与 RR 在复制方面的区别

1> RC 隔离级别不支持 statement 格式的 bin log，因为该格式的复制，会导致主从数据的不一致；只能使用 mixed 或者 row 格式的 bin log; 这也是为什么 MySQL 默认使用 RR 隔离级别的原因。复制时，我们最好使用：binlog_format=row

具体参见：

http://www.linuxidc.com/Linux/2017-02/140846.htm

http://www.linuxidc.com/Linux/2017-02/140847.htm

2> MySQL5.6 的早期版本，RC 隔离级别是可以设置成使用 statement 格式的 bin log，后期版本则会直接报错；

5.3 RC 与 RR 在一致性读方面的区别

简单而且，RC 隔离级别时，事务中的每一条 select 语句会读取到他自己执行时已经提交了的记录，也就是每一条 select 都有自己的一致性读 ReadView; 而 RR 隔离级别时，事务中的一致性读的 ReadView 是以第一条 select 语句的运行时，作为本事务的一致性读 snapshot 的建立时间点的。只能读取该时间点之前已经提交的数据。

具体可以参加：MySQL 一致性读深入研究

5.4 RC 支持半一致性读，RR 不支持

RC 隔离级别下的 update 语句，使用的是半一致性读(semi consistent)；而 RR 隔离级别的 update 语句使用的是当前读；当前读会发生锁的阻塞。

1> 半一致性读：

A type of read operation used for UPDATE statements, that is a combination of read committed and consistent read. When an UPDATE statement examines a row that is already locked, InnoDB returns the latest committed version to MySQL so that MySQL can determine whether the row matches the WHERE condition of the UPDATE. If the row matches (must be updated), MySQL reads the row again, and this time InnoDB either locks it or waits for a lock on it. This type of read operation can only happen when the transaction has the read committed isolation level, or when the innodb_locks_unsafe_for_binlog option is enabled.

简单来说，semi-consistent read 是 read committed 与 consistent read 两者的结合。一个 update 语句，如果读到一行已经加锁的记录，此时 InnoDB 返回记录最近提交的版本，由 MySQL 上层判断此版本是否满足 update 的 where 条件。若满足(需要更新)，则 MySQL 会重新发起一次读操作，此时会读取行的最新版本(并加锁)。semi-consistent read 只会发生在 read committed 隔离级别下，或者是参数 innodb_locks_unsafe_for_binlog 被设置为 true(该参数即将被废弃)。

对比 RR 隔离级别，update 语句会使用当前读，如果一行被锁定了，那么此时会被阻塞，发生锁等待。而不会读取最新的提交版本，然后来判断是否符合 where 条件。

半一致性读的优点：

减少了 update 语句时行锁的冲突；对于不满足 update 更新条件的记录，可以提前放锁，减少并发冲突的概率。

具体可以参见：http://www.linuxidc.com/Linux/2017-02/140844.htm

Oracle 中的 update 好像有“重启动”的概念。

本文永久更新链接地址：http://www.linuxidc.com/Linux/2017-02/140843.htm