MySQL 一致性讀深刻研究

時間 2019-11-05

原文原文鏈接

一致性讀，又稱爲快照讀。使用的是MVCC機制讀取undo中的已經提交的數據。因此它的讀取是非阻塞的。html

相關文檔：http://dev.mysql.com/doc/refman/5.6/en/innodb-consistent-read.htmlmysql

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.sql

一致性讀確定是讀取在某個時間點已經提交了的數據，有個特例：本事務中修改的數據，即便未提交的數據也能夠在本事務的後面部分讀取到。數據庫

1. RC 隔離和 RR 隔離中一致性讀的區別session

根據隔離級別的不一樣，一致性讀也是不同的。不一樣點在於判斷是否提交的「某個時間點」：app

1）對於RR隔離：ide

文檔中說的是：the first such read in that transaction。實際上實驗的結果代表，這裏的 the first such read指的是：對同一個表或者不一樣表進行的第一次select語句創建了該事務中一致性讀的snapshot. 其它update, delete, insert 語句和一致性讀snapshot的創建沒有關係。在snapshot創建以後提交的數據，一致性讀就讀不到，以前提交的數據就能夠讀到。this

事務的起始點實際上是以執行的第一條語句爲起始點的，而不是以begin做爲事務的起始點的。spa

實驗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」.