MySQL中隔离级别RC与RR的区别
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
YES YES YES
UNCOMMITTED
READ
NO YES YES
COMMITTED
READ
NO NO YES
REPEATABLE
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：
下⾯是来⾃ itpub 的⼀个例⼦：www.itpub/thread-1941624-1-1.html
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>2and b<5and c=2;
执⾏计划如下：
mysql> explain select*from t1 where b>2and b<5and c=2\G
***************************1. row ***************************
id: 1
log4j哪个版本有漏洞
select_type: SIMPLEc语言那本书适合自学
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是什么系统
mysql>select*from t1 where b>2and 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隔离级别下的加锁过程
下⾯是官⽅⽂档中的说明：sql/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=3and 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
具体参见：
blog.itpub/29254281/viewspace-1081678/
wwwblogs/vinchen/archive/2012/11/19/2777919.html
2> MySQL5.6 的早期版本，RC隔离级别是可以设置成使⽤statement格式的bin log，后期版本则会直
ajax传输json数据格式接报错；
5.3 RC 与 RR 在⼀致性读⽅⾯的区别
简单⽽且，RC隔离级别时，事务中的每⼀条select语句会读取到他⾃⼰执⾏时已经提交了的记录，也就是每⼀条select都有⾃⼰的⼀致性读ReadView; ⽽RR隔离级别时，事务中的⼀致性读的ReadView是以第⼀条select语句的运⾏时，作为本事务的⼀致性读snapshot的建⽴时间点的。只能读取该时间点之前已经提交的数据。
具体可以参加：
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隔离级别下，或者是参数被设置为true(该参数即将被废弃)。
对⽐RR隔离级别，update语句会使⽤当前读，如果⼀⾏被锁定了，那么此时会被阻塞，发⽣锁等待。⽽不会读取最新的提交版本，然后来判断是否符合where 条件。
半⼀致性读的优点：
减少了update语句时⾏锁的冲突；对于不满⾜update更新条件的记录，可以提前放锁，减少并发冲突
ant驱动程序安装
fastreport二维码控件的概率。
具体可以参见：hedengcheng/?p=220
Oracle中的update好像有“重启动”的概念。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。