zoukankan html css js c++ java

MySQL 一致性读深入研究

一致性读，又称为快照读。使用的是MVCC机制读取undo中的已经提交的数据。所以它的读取是非阻塞的。

相关文档：http://dev.mysql.com/doc/refman/5.6/en/innodb-consistent-read.html

A consistent read means that InnoDB uses multi-versioning to present to a query a snapshot of the database at a point in time. The query sees the changes made by transactions that committed before that point of time, and no changes made by later or uncommitted transactions. The exception to this rule is that the query sees the changes made by earlier statements within the same transaction.

一致性读肯定是读取在某个时间点已经提交了的数据，有个特例：本事务中修改的数据，即使未提交的数据也可以在本事务的后面部分读取到。

1. RC 隔离和 RR 隔离中一致性读的区别

根据隔离级别的不同，一致性读也是不一样的。不同点在于判断是否提交的“某个时间点”：

1）对于RR隔离：

If the transaction isolation level is REPEATABLE READ (the default level), all consistent reads within the same transaction read the snapshot established by the first such read in that transaction.

文档中说的是：the first such read in that transaction。实际上实验的结果表明，这里的 the first such read指的是：对同一个表或者不同表进行的第一次select语句建立了该事务中一致性读的snapshot. 其它update, delete, insert 语句和一致性读snapshot的建立没有关系。在snapshot建立之后提交的数据，一致性读就读不到，之前提交的数据就可以读到。

事务的起始点其实是以执行的第一条语句为起始点的，而不是以begin作为事务的起始点的。

实验1：

sesseion A	session B
mysql> set tx_isolation='repeatable-read'; Query OK, 0 rows affected (0.00 sec)	mysql> set tx_isolation='repeatable-read'; Query OK, 0 rows affected (0.00 sec)
mysql> begin; Query OK, 0 rows affected (0.01 sec)
	mysql> select * from t1; Empty set (0.00 sec) mysql> insert into t1(c1,c2) values(1,1); Query OK, 1 row affected (0.01 sec)
mysql> select * from t1; +----+------+ \| c1 \| c2 \| +----+------+ \| 1 \| 1 \| +----+------+ 1 row in set (0.00 sec)

上面的实验说明：RR隔离级别下的一致性读，不是以begin开始的时间点作为snapshot建立时间点，而是以第一条select语句的时间点作为snapshot建立的时间点。

实验2：

session A	session B
mysql> set tx_isolation='repeatable-read';	mysql> set tx_isolation='repeatable-read';
	mysql> select * from t1; Empty set (0.00 sec)
mysql> begin; mysql> select * from t;
	mysql> insert into t1(c1,c2) values(1,1); Query OK, 1 row affected (0.01 sec)
mysql> select * from t1; Empty set (0.00 sec)

该使用说明：RR隔离级别下的一致性读，是以第一条select语句的执行点作为snapshot建立的时间点的，即使是不同表的select语句。这里因为session A在insert之前对 t 表执行了select，所以建立了snapshot，所以后面的select * from t1 不能读取到insert的插入的值。

实验3：

session A	session B
mysql> set tx_isolation='repeatable-read';	mysql> set tx_isolation='repeatable-read'; mysql> select * from t1; Empty set (0.00 sec)
mysql> begin;
mysql> select * from t1; Empty set (0.00 sec)	mysql> select * from t1; Empty set (0.00 sec)
	mysql> insert into t1(c1,c2) values(1,1);
mysql> select * from t1; Empty set (0.01 sec)

该实验中：session A 的第一条语句，发生在session B的 insert语句提交之前，所以session A中的第二条select还是不能读取到数据。因为RR中的一致性读是以事务中第一个select语句执行的时间点作为snapshot建立的时间点的。而此时，session B的insert语句还没有执行，所以读取不到数据。

实验4：

session A	session B
mysql> set tx_isolation='repeatable-read';	mysql> set tx_isolation='repeatable-read'; mysql> select * from t1; Empty set (0.00 sec)
mysql> select * from t1; Empty set (0.00 sec)
	mysql> insert into t1(c1,c2) values(1,1),(2,2); mysql> select * from t1; +----+------+ \| c1 \| c2 \| +----+------+ \| 1 \| 1 \| \| 2 \| 2 \| +----+------+ 2 rows in set (0.01 sec)
mysql> select * from t1; Empty set (0.00 sec)
mysql> update t1 set c2=100 where c1=1; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 mysql> select * from t1; +----+------+ \| c1 \| c2 \| +----+------+ \| 1 \| 100 \| +----+------+ 1 row in set (0.00 sec)

该实验说明：本事务中进行修改的数据，即使没有提交，在本事务中的后面也可以读取到。update 语句因为进行的是“当前读”，所以它可以修改成功。

2）对于RC隔离就简单多了：

With READ COMMITTED isolation level, each consistent read within a transaction sets and reads its own fresh snapshot.

事务中每一次读取都是以当前的时间点作为判断是否提交的实际点，也即是 reads its own fresh snapshot.

RC是语句级多版本(事务的多条只读语句，创建不同的ReadView，代价更高)，RR是事务级多版本(一个ReadView)；

3. MySQL 中事务开始的时间

一般我们会认为 begin/start transaction 是事务开始的时间点，也就是一旦我们执行了 start transaction，就认为事务已经开始了，其实这是错误的。上面的实验也说明了这一点。事务开始的真正的时间点(LSN)，是 start transaction 之后执行的第一条语句，不管是什么语句，不管成功与否。

但是如果你想要达到将 start transaction 作为事务开始的时间点，那么我们必须使用：

START TRANSACTION WITH consistent snapshot

它的含义是：执行 start transaction 同时建立本事务一致性读的 snapshot . 而不是等到执行第一条语句时，才开始事务，并且建立一致性读的 snapshot .

The WITH CONSISTENT SNAPSHOT modifier starts a consistent read for storage engines that are capable of it. This applies only to InnoDB. The effect is the same as issuing a START TRANSACTION followed by a SELECT from any InnoDB table. See Section 14.2.2.2, “Consistent Nonlocking Reads”. The WITH CONSISTENT SNAPSHOT modifier does not change the current transaction isolation level, so it provides a consistent snapshot only if the current isolation level is one that permits a consistent read. The only isolation level that permits a consistent read is REPEATABLE READ. For all other isolation levels, the WITH CONSISTENT SNAPSHOT clause is ignored. As of MySQL 5.7.2, a warning is generated when the WITH CONSISTENT SNAPSHOT clause is ignored.

http://dev.mysql.com/doc/refman/5.6/en/commit.html
效果等价于： start transaction 之后，马上执行一条 select 语句(此时会建立一致性读的snapshot)。

If the transaction isolation level is REPEATABLE READ (the default level), all consistent reads within the same transaction read the snapshot established by the first such read in that transaction. You can get a fresher snapshot for your queries by committing the current transaction and after that issuing new queries. (RR隔离级别中的一致性读的snapshot是第一条select语句执行时建立的，其实应该是第一条任何语句执行时建立的)

http://dev.mysql.com/doc/refman/5.6/en/innodb-consistent-read.html

我们在 mysqldump --single-transaction 中使用的就是该语句：

SET session TRANSACTION isolation LEVEL REPEATABLE read
START TRANSACTION /*!40100 WITH consistent snapshot */

所以事务开始时间点，分为两种情况：

1）START TRANSACTION 时，是第一条语句的执行时间点，就是事务开始的时间点，第一条select语句建立一致性读的snapshot；

2）START TRANSACTION WITH consistent snapshot 时，则是立即建立本事务的一致性读snapshot，当然也开始事务了；

实验1：

session A	session B
mysql> set tx_isolation='repeatable-read';	mysql> set tx_isolation='repeatable-read';
	mysql> select * from t1; Empty set (0.01 sec)
mysql> start transaction;
	mysql> insert into t1(c1,c2) values(1,1);
mysql> select * from t1; +----+------+ \| c1 \| c2 \| +----+------+ \| 1 \| 1 \| +----+------+ 1 row in set (0.00 sec)

实验2：

mysql> set tx_isolation='repeatable-read';	mysql> set tx_isolation='repeatable-read';
	mysql> select * from t1; Empty set (0.01 sec)
mysql> start transaction with consistent snapshot;
	mysql> insert into t1(c1,c2) values(1,1);
mysql> select * from t1; Empty set (0.00 sec)

上面两个实验很好的说明了 start transaction 和 start tansaction with consistent snapshot的区别。第一个实验说明，start transaction执行之后，事务并没有开始，所以insert发生在session A的事务开始之前，所以可以读到session B插入的值。第二个实验说明，start transaction with consistent snapshot已经开始了事务，所以insert语句发生在事务开始之后，所以读不到insert的数据。

3. Oracle中的一致性读

Oracle读一致性是指一个查询所获得的数据来自同一时间点。

Oracle读一致性分为语句级读一致性和事务级读一致性。

语句级读一致性：Oracle强制实现语句级读一致性。一个查询语句只读取语句开始之前提交的数据。

事务级读一致性：隔离级别为SERIALIZABLE和read only的事务才支持事务级读一致性。事务中的所有查询语句只读取事务开始之前提交的数据。

Oracle只实现了RC和serializable，没有实现Read uncommitted 和 RR。其实Oracle的serializable级别才实现了可重复读。

4. 当前读(current read) 和一致性读

一致性读是指普通的select语句，不带 for update, in share mode 等等子句。使用的是undo中的提交的数据，不需要使用锁(MDL除外)。而当前读，是指update, delete, select for update, select in share mode等等语句进行的读，它们读取的是数据库中的最新的数据，并且会锁住读取的行和gap(RR隔离时)。如果不能获得锁，则会一直等待，直到获得或者超时。RC隔离级别的当前读没有gap lock，RC的update语句进行的是“半一致性读”，和RR的update语句的当前读不一样。

5. 一致性读与 mysqldump --single-transaction

我们知道 mysqldump --single-transaction的原理是：设置事务为RR模式，然后利用事务的特性，来获得一致性的数据，但是：

--single-transaction
                      Creates a consistent snapshot by dumping all tables in a
                      single transaction. Works ONLY for tables stored in
                      storage engines which support multiversioning (currently
                      only InnoDB does); the dump is NOT guaranteed to be
                      consistent for other storage engines. While a
                      --single-transaction dump is in process, to ensure a
                      valid dump file (correct table contents and binary log
                      position), no other connection should use the following
                      statements: ALTER TABLE, DROP TABLE, RENAME TABLE,
                      TRUNCATE TABLE, as consistent snapshot is not isolated
                      from them. Option automatically turns off --lock-tables.

在mysqldump运行期间，不能执行 alter table, drop table, rename table, truncate table 等等的DDL语句，因为一致性读和这些语句时无法隔离的。

那么在mysqldump --single-transaction 执行期间，执行了上面那些DDL，会发生什么呢？

mysqldump --single-transaction 的执行过程是：设置RR，然后开始事务，对应了一个LSN，然后对所有选中的表，一个一个的执行下面的过程：

save point sp; --> select * from t1 --> rollback to sp;

save point sp; --> select * from t2 --> rollback to sp;

... ...

1> 那么如果对t2表的DDL发生在 save point sp 之前，那么当mysqldump处理到 t2 表时，mysqldump 会立马报错：表结构已经改变......

2> 如果对t2表的DDL发生在 save point sp 之后，rollback to sp 之前，那么要么DDL被阻塞，要么mysqldump被阻塞，具体谁被阻塞，看谁先执行了。

被阻塞额原因是：DDL需要t2表的 MDL 的互斥锁，而select * from t1 需要MDL的共享锁，所以阻塞发生。

3> 如果对t2表的DDL发生在 rollback to sp 之后，那么因为对 t2 表的dump已经完成，不会发生错误或者阻塞。

那么为什么：对t2表的DDL发生在 save point sp 之前，那么当mysqldump开始处理 t2 表时，mysqldump 立马报错呢？

其原因就是一致性读的胳膊拗不过DDL的大腿：

Consistent read does not work over certain DDL statements:(一致性读的胳膊拗不过DDL的大腿)

Consistent read does not work over DROP TABLE, because MySQL cannot use a table that has been dropped and InnoDB destroys the table.
Consistent read does not work over ALTER TABLE, because that statement makes a temporary copy of the original table and deletes the original table when the temporary copy is built. When you reissue a consistent read within a transaction, rows in the new table are not visible because those rows did not exist when the transaction's snapshot was taken. In this case, the transaction returns an error as of MySQL 5.6.6: ER_TABLE_DEF_CHANGED, “Table definition has changed, please retry transaction”.

原因：ALTER TABLE, DROP TABLE, RENAME TABLE, TRUNCATE TABLE 这些DDL语句的执行，会导致无法使用undo构造出正确的一致性读，一致性读和它们是无法隔离的。

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 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：

下面是来自 itpub 的一个例子：http://www.itpub.net/thread-1941624-1-1.html

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

表结构：

mysql> show create table t1G
*************************** 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=2G
*************************** 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://blog.itpub.net/29254281/viewspace-1081678/

http://www.cnblogs.com/vinchen/archive/2012/11/19/2777919.html

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://hedengcheng.com/?p=220

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

查看全文

相关阅读:
Nmap帮助文档解释
 用servlet设置过滤器处理中文乱码
 Linux服务器远程连接window服务器并执行cmd命令
 java中的异常处理
 java的反射机制
 react入门
 多线程编程
 软件工程基本概念
 反射、类加载与垃圾回收
 数据库

原文地址：https://www.cnblogs.com/DataArt/p/10095339.html

MySQL 一致性读 深入研究

MySQL 一致性读深入研究