MySQL默認隔離級別爲何是RR

時間  2020-04-11
標籤 mysql 默認 隔離 級別 爲何 欄目 MySQL 简体版
原文   原文鏈接

曾屢次聽到「MySQL爲何選擇RR爲默認隔離級別」的問題，其實這是個歷史遺留問題，當前以及解決，可是MySQL的各個版本沿用了原有習慣。歷史版本中的問題是什麼，本次就經過簡單的測試來講明一下。mysql

一、 準備工做

1.1 部署主從

部署一套主從架構的集羣，建立過程較簡單，能夠參考歷史文章部署 MySQL主從複製搭建 部署一主一從便可。sql

 

 

 1.2 建立測試表及數據

在主庫中建立表及測試數據數據庫

mysql> create table users(id int primary key auto_increment,user_name varchar(20),c_id tinyint(4),c_note varchar(50),key c_id(c_id)) engine=innodb;
Query OK, 0 rows affected (0.01 sec)

mysql> insert into users values(1,'劉備',2,null),(2,'曹操',1,null),(3,'孫權',3,null),(4,'關羽',2,null),(5,'司馬懿',1,null);
Query OK, 5 rows affected (0.00 sec)
Records: 5  Duplicates: 0  Warnings: 0

mysql> create table  class(c_id int primary key ,c_name  varchar(1),c_note varchar(50)) engine=innodb;
Query OK, 0 rows affected (0.00 sec)

mysql> insert into class values(1,'魏',null),(2,'蜀',null),(3,'吳',null),(4,'晉','');
Query OK, 4 rows affected (0.00 sec)
Records: 4  Duplicates: 0  Warnings: 0

 

二、 RR隔離級別 

MySQL默認的隔離級別爲 RR（Repeatable Read），在此隔離級別下，對比binlog格式爲ROW、STATEMENT是否會形成主從數據不一致session

2.1  ROW格式

其實不用測試你們也應該對RR級別下ROW格式的binlog有信心，可是，萬事皆需實踐檢驗。架構

步驟說明以下：app

  • 步驟1 -   分別查看兩個會話中的事務隔離級別及binlog格式（隔離級別均爲RR，binlog爲ROW格式）
  • 步驟2 -   SESSION A 開啓事務，更新users 表中c_id字段存在於class表中的記錄，結果爲5條記錄均更新，並將c_note內容更新爲 t1
  • 步驟3-   SESSION B 開啓事務，準備刪除class表中 c_id等於2的記錄，此時沒法更新，處於阻塞狀態，由於在RR級別下須要保證重複讀。達到所等待超時時間後將會報錯。
  • 步驟4-   SESSION A 提交事務（此步驟也能夠在步驟3時操做，結果不同，後續步驟中將採用此方式）
  • 步驟5-   SESSION B 重啓事務，再次刪除class表中 c_id等於2的記錄，此時提交能夠成功了，成功刪除了一條記錄
  • 步驟6-   SESSION A  開啓事務，更新users 表中c_id字段存在於class表中的記錄，結果爲3條記錄更新成功，並將c_note內容更新爲 t2，有2條記錄由於c_id不存在與class表中，所以不會更新
  • 步驟7-  分別在SESSON A和SESSION B查看users表中的內容，結果一致
  • 步驟8-  在從庫查看users表中的內容，數據與主庫一致

具體步驟以下：測試

 
步驟 SESSION A

SESSION Bspa
1

mysql>show  variables like '%iso%';rest

+-----------------------+-----------------+日誌

| Variable_name         | Value           |

+-----------------------+-----------------+

| transaction_isolation | REPEATABLE-READ |

| tx_isolation          | REPEATABLE-READ |

+-----------------------+-----------------+

2 rows in set (0.00 sec)

 

mysql>show  variables like '%binlog_format%';

+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| binlog_format | ROW   |

+---------------+-------+

1 row in set (0.00 sec)

mysql>show  variables like '%iso%';

+-----------------------+-----------------+

| Variable_name         | Value           |

+-----------------------+-----------------+

| transaction_isolation | REPEATABLE-READ |

| tx_isolation          | REPEATABLE-READ |

+-----------------------+-----------------+

2 rows in set (0.00 sec)

 

mysql>show  variables like '%binlog_format%';

+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| binlog_format | ROW   |

+---------------+-------+

1 row in set (0.01 sec)

 

 

 
2

mysql>set autocommit=0;

mysql>update users set c_note='t1' where c_id in (select  c_id from  class);

Query OK, 5 rows affected (0.00 sec)

Rows matched: 5  Changed: 5  Warnings: 0

 

 

 

 

  
3  

mysql>set autocommit=0;

Query OK, 0 rows affected (0.00 sec)

 

mysql>delete  from class where c_id=2;

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

 

 

 

 

 
4

mysql>commit;

Query OK, 0 rows affected (0.00 sec)

 

  
5  

mysql>set autocommit=0;

Query OK, 0 rows affected (0.00 sec)

 

mysql>delete  from class where c_id=2;

Query OK, 1 row affected (0.00 sec)

 

mysql>commit;

Query OK, 0 rows affected (0.00 sec)

 
6

mysql>update users set c_note='t2' where c_id in (select  c_id from  class);

Query OK, 3 rows affected (0.00 sec)

Rows matched: 3  Changed: 3  Warnings: 0

 

mysql>commit;

Query OK, 0 rows affected (0.00 sec)

 

 

  
7

mysql>select  * from users;

+----+-----------+------+--------+

| id | user_name | c_id | c_note |

+----+-----------+------+--------+

|  1 | 劉備      |    2 | t1     |

|  2 | 曹操      |    1 | t2     |

|  3 | 孫權      |    3 | t2     |

|  4 | 關羽      |    2 | t1     |

|  5 | 司馬懿    |    1 | t2     |

+----+-----------+------+--------+

5 rows in set (0.00 sec)

 

 

mysql>select  * from users;

+----+-----------+------+--------+

| id | user_name | c_id | c_note |

+----+-----------+------+--------+

|  1 | 劉備      |    2 | t1     |

|  2 | 曹操      |    1 | t2     |

|  3 | 孫權      |    3 | t2     |

|  4 | 關羽      |    2 | t1     |

|  5 | 司馬懿    |    1 | t2     |

+----+-----------+------+--------+

5 rows in set (0.00 sec)

 

 
8

在從庫查看數據

root@testdb:3307 12:02:20>select * from users;

+----+-----------+------+--------+

| id | user_name | c_id | c_note |

+----+-----------+------+--------+

|  1 | 劉備      |    2 | t1     |

|  2 | 曹操      |    1 | t2     |

|  3 | 孫權      |    3 | t2     |

|  4 | 關羽      |    2 | t1     |

|  5 | 司馬懿    |    1 | t2     |

+----+-----------+------+--------+

 

5 rows in set (0.00 sec)

 

 

2.2  STATEMENT格式

爲了和以前的步驟一致，先初始化數據

root@testdb:3306 12:14:27>truncate table  users;
Query OK, 0 rows affected (0.08 sec)

root@testdb:3306 12:14:29>truncate table  class;
Query OK, 0 rows affected (0.04 sec)

root@testdb:3306 12:14:50>insert into users values(1,'劉備',2,null),(2,'曹操',1,null),(3,'孫 權',3,null),(4,'關羽',2,null),(5,'司馬懿',1,null);
Query OK, 5 rows affected (0.00 sec)
Records: 5  Duplicates: 0  Warnings: 0

root@testdb:3306 12:15:10>insert into class values(1,'魏',null),(2,'蜀',null),(3,'吳',null),(4,'晉','');
Query OK, 4 rows affected (0.00 sec)
Records: 4  Duplicates: 0  Warnings: 0

再將binlog日誌格式改成STATAMENT格式（全局及會話級都改一下，或者修改全局變量後從新登陸也行，固然 只改會話級別的也能夠測試），而後 再次進行測試。

步驟說明以下：

  • 步驟1 -   分別查看兩個會話中的事務隔離級別及binlog格式（隔離級別均爲RR，binlog爲STATENENT格式）
  • 步驟2 -   SESSION A 開啓事務，更新users 表中c_id字段存在於class表中的記錄，結果爲5條記錄均更新，並將c_note內容更新爲 t1
  • 步驟3-   SESSION B 開啓事務，準備刪除class表中 c_id等於2的記錄，此時沒法更新，處於阻塞狀態，當即進行步驟4
  • 步驟4-    SESSION A 在SESSION B執行commit的動做，則SESSION B的刪除操做能夠執行經過，但注意class表的數據兩個SESSION中查看到的是不同的
  • 步驟5-   此時SESSION B執行commit,不然後面session A 更新數據時也會阻塞。此時若是SESSION A不執行commit，查看class表的結果也是不同的，如步驟中的狀況
  • 步驟6-   SESSION A  開啓事務，更新users 表中c_id字段存在於class表中的記錄，結果爲3條記錄更新成功，並將c_note內容更新爲 t2，另外2條記錄雖然本此時查看class表中存在對應的c_id，可是不會更新，此時提交事務，而後再次查看class的內容，結果和SESSION B 查看的結果一致了（幻讀）
  • 步驟7-  在從庫查看users、class表中的內容，數據與主庫一致

 

步  驟 SESSION A SESSION B
1               

mysql>show  variables  like '%iso%';

+-----------------------+-----------------+

| Variable_name         | Value           |

+-----------------------+-----------------+

| transaction_isolation | REPEATABLE-READ |

| tx_isolation          | REPEATABLE-READ |

+-----------------------+-----------------+

2 rows in set (0.01 sec)

 

mysql>show  variables  like '%binlog_format%';

+---------------+-----------+

| Variable_name | Value     |

+---------------+-----------+

| binlog_format | STATEMENT |

+---------------+-----------+

1 row in set (0.01 sec)

 

mysql>show  variables  like '%iso%';

+-----------------------+-----------------+

| Variable_name         | Value           |

+-----------------------+-----------------+

| transaction_isolation | REPEATABLE-READ |

| tx_isolation          | REPEATABLE-READ |

+-----------------------+-----------------+

2 rows in set (0.01 sec)

 

mysql>show  variables  like '%binlog_format%';

+---------------+-----------+

| Variable_name | Value     |

+---------------+-----------+

| binlog_format | STATEMENT |

+---------------+-----------+

1 row in set (0.01 sec)
2

root@testdb:3306 12:37:04>set autocommit=0;

Query OK, 0 rows affected (0.00 sec)

 

root@testdb:3306 12:37:17>update users set c_note='t1' where c_id in (select  c_id from  class);

Query OK, 5 rows affected, 1 warning (0.00 sec)

Rows matched: 5  Changed: 5  Warnings: 1

 

 

 

 

 

 

 
3  

root@testdb:3306 12:28:25>set autocommit=0;

Query OK, 0 rows affected (0.00 sec)

 

root@testdb:3306 12:38:06>delete  from class where c_id=2;

Query OK, 1 row affected (4.74 sec)
4

root@testdb:3306 12:38:09>commit;

Query OK, 0 rows affected (0.00 sec)

 

root@testdb:3306 12:38:13>select  * from users;

+----+-----------+------+--------+

| id | user_name | c_id | c_note |

+----+-----------+------+--------+

|  1 | 劉備      |    2 | t1     |

|  2 | 曹操      |    1 | t1     |

|  3 | 孫 權     |    3 | t1     |

|  4 | 關羽      |    2 | t1     |

|  5 | 司馬懿    |    1 | t1     |

+----+-----------+------+--------+

5 rows in set (0.00 sec)

 

root@testdb:3306 12:39:07>select  * from class;

+------+--------+--------+

| c_id | c_name | c_note |

+------+--------+--------+

|    1 | 魏     | NULL   |

|    2 | 蜀     | NULL   |

|    3 | 吳     | NULL   |

|    4 | 晉     |        |

+------+--------+--------+

4 rows in set (0.00 sec)

 

 

 

 

 
5  

root@testdb:3306 12:38:13>commit;

Query OK, 0 rows affected (0.00 sec)

 

root@testdb:3306 12:39:56>select *  from class ;

+------+--------+--------+

| c_id | c_name | c_note |

+------+--------+--------+

|    1 | 魏     | NULL   |

|    3 | 吳     | NULL   |

|    4 | 晉     |        |

+------+--------+--------+

3 rows in set (0.00 sec)
6

root@testdb:3306 12:52:23>update users set c_note='t2' where c_id in (select  c_id from  class);

Query OK, 3 rows affected, 1 warning (0.00 sec)

Rows matched: 3  Changed: 3  Warnings: 1

 

root@testdb:3306 12:52:45>select  * from class;

+------+--------+--------+

| c_id | c_name | c_note |

+------+--------+--------+

|    1 | 魏     | NULL   |

|    2 | 蜀     | NULL   |

|    3 | 吳     | NULL   |

|    4 | 晉     |        |

+------+--------+--------+

4 rows in set (0.00 sec)

 

root@testdb:3306 12:52:49>select  * from users;

+----+-----------+------+--------+

| id | user_name | c_id | c_note |

+----+-----------+------+--------+

|  1 | 劉備      |    2 | t1     |

|  2 | 曹操      |    1 | t2     |

|  3 | 孫 權     |    3 | t2     |

|  4 | 關羽      |    2 | t1     |

|  5 | 司馬懿    |    1 | t2     |

+----+-----------+------+--------+

5 rows in set (0.01 sec)

 

root@testdb:3306 12:53:03>commit;

Query OK, 0 rows affected (0.00 sec)

 

root@testdb:3306 12:53:06>select  * from users;

+----+-----------+------+--------+

| id | user_name | c_id | c_note |

+----+-----------+------+--------+

|  1 | 劉備      |    2 | t1     |

|  2 | 曹操      |    1 | t2     |

|  3 | 孫 權     |    3 | t2     |

|  4 | 關羽      |    2 | t1     |

|  5 | 司馬懿    |    1 | t2     |

+----+-----------+------+--------+

5 rows in set (0.00 sec)

 

root@testdb:3306 12:53:11>select  * from class;

+------+--------+--------+

| c_id | c_name | c_note |

+------+--------+--------+

|    1 | 魏     | NULL   |

|    3 | 吳     | NULL   |

|    4 | 晉     |        |

+------+--------+--------+

3 rows in set (0.00 sec)

  
7

查看從庫數據

root@testdb:3307 12:44:22>select  * from  class;

+------+--------+--------+

| c_id | c_name | c_note |

+------+--------+--------+

|    1 | 魏     | NULL   |

|    3 | 吳     | NULL   |

|    4 | 晉     |        |

+------+--------+--------+

3 rows in set (0.01 sec)

 

root@testdb:3307 12:57:07>select  * from  users;

+----+-----------+------+--------+

| id | user_name | c_id | c_note |

+----+-----------+------+--------+

|  1 | 劉備      |    2 | t1     |

|  2 | 曹操      |    1 | t2     |

|  3 | 孫 權     |    3 | t2     |

|  4 | 關羽      |    2 | t1     |

|  5 | 司馬懿    |    1 | t2     |

+----+-----------+------+--------+

5 rows in set (0.00 sec)

也就是此時主從結果也是一致的，緣由在於，binlog裏存儲的語句順序以下：

binlog裏的順序 語句內容
1

update users set c_note='t1' where c_id in (select  c_id from  class);

 

 
2 delete  from class where c_id=2;
3 update users set c_note='t2' where c_id in (select  c_id from  class);

與主庫執行的順序是一致的，所以，主從的結果是一致的。

三、 RC隔離級別 

3.1  ROW格式

爲了和以前的步驟一致，先初始化數據

root@testdb:3306 12:14:27>truncate table  users;
Query OK, 0 rows affected (0.08 sec)

root@testdb:3306 12:14:29>truncate table  class;
Query OK, 0 rows affected (0.04 sec)

root@testdb:3306 12:14:50>insert into users values(1,'劉備',2,null),(2,'曹操',1,null),(3,'孫 權',3,null),(4,'關羽',2,null),(5,'司馬懿',1,null);
Query OK, 5 rows affected (0.00 sec)
Records: 5  Duplicates: 0  Warnings: 0

root@testdb:3306 12:15:10>insert into class values(1,'魏',null),(2,'蜀',null),(3,'吳',null),(4,'晉','');
Query OK, 4 rows affected (0.00 sec)
Records: 4  Duplicates: 0  Warnings: 0

再將binlog日誌格式改成STATAMENT格式（全局及會話級都改一下，或者修改全局變量後從新登陸也行，固然 只改會話級別的也能夠測試），而後 再次進行測試。

步驟說明以下：

  • 步驟1 -   分別查看兩個會話中的事務隔離級別及binlog格式（隔離級別均爲RC，binlog爲ROW格式）
  • 步驟2 -   SESSION A 開啓事務，更新users 表中c_id字段存在於class表中的記錄，結果爲5條記錄均更新，並將c_note內容更新爲 t1
  • 步驟3-   SESSION B 開啓事務，準備刪除class表中 c_id等於2的記錄，此時不會像RR事務隔離級別那樣處於阻塞狀態，而是能夠直接執行經過
  • 步驟4-   此時SESSION A查看class數據仍是刪除前的，由於session B 暫未提交
  • 步驟5-   SESSION B 提交事務，
  • 步驟6-   更新users 表中c_id字段存在於class表中的記錄，結果爲3條記錄更新成功，並將c_note內容更新爲 t2
  • 步驟7-  在從庫查看users、class表中的內容，數據與主庫一致
步  驟 SESSION A SESSION B
1               

root@testdb:3306 01:25:24>show  variables  like '%iso%';

+-----------------------+----------------+

| Variable_name         | Value          |

+-----------------------+----------------+

| transaction_isolation | READ-COMMITTED |

| tx_isolation          | READ-COMMITTED |

+-----------------------+----------------+

2 rows in set (0.01 sec)

 

root@testdb:3306 01:25:36>show  variables  like '%binlog_format%';

+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| binlog_format | ROW   |

+---------------+-------+

1 row in set (0.01 sec)

root@testdb:3306 01:24:57>show  variables  like '%iso%';

+-----------------------+----------------+

| Variable_name         | Value          |

+-----------------------+----------------+

| transaction_isolation | READ-COMMITTED |

| tx_isolation          | READ-COMMITTED |

+-----------------------+----------------+

2 rows in set (0.01 sec)

 

root@testdb:3306 01:25:39>show  variables  like '%binlog_format%';

+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| binlog_format | ROW   |

+---------------+-------+

1 row in set (0.00 sec)
2

root@testdb:3306 01:27:55>set autocommit=0;

Query OK, 0 rows affected (0.00 sec)

 

root@testdb:3306 01:28:27>update users set c_note='t1' where c_id in (select  c_id from  class);

Query OK, 5 rows affected (0.00 sec)

Rows matched: 5  Changed: 5  Warnings: 0

 

 

 

 
3

 

root@testdb:3306 01:26:07>set autocommit=0;

Query OK, 0 rows affected (0.00 sec)

 

root@testdb:3306 01:28:37>delete  from class where c_id=2;

Query OK, 1 row affected (0.00 sec)

 

 

 

 

 
4

root@testdb:3306 01:28:27>select  * from class;

+------+--------+--------+

| c_id | c_name | c_note |

+------+--------+--------+

|    1 | 魏     | NULL   |

|    2 | 蜀     | NULL   |

|    3 | 吳     | NULL   |

|    4 | 晉     |        |

+------+--------+--------+

4 rows in set (0.00 sec)

 
5  

root@testdb:3306 01:28:41>commit;

Query OK, 0 rows affected (0.00 sec)
6

root@testdb:3306 01:28:59>select  * from class;

+------+--------+--------+

| c_id | c_name | c_note |

+------+--------+--------+

|    1 | 魏     | NULL   |

|    3 | 吳     | NULL   |

|    4 | 晉     |        |

+------+--------+--------+

3 rows in set (0.01 sec)

 

root@testdb:3306 01:29:13>update users set c_note='t2' where c_id in (select  c_id from  class);

Query OK, 3 rows affected (0.00 sec)

Rows matched: 3  Changed: 3  Warnings: 0

 

root@testdb:3306 01:29:26>select  * from class;

+------+--------+--------+

| c_id | c_name | c_note |

+------+--------+--------+

|    1 | 魏     | NULL   |

|    3 | 吳     | NULL   |

|    4 | 晉     |        |

+------+--------+--------+

3 rows in set (0.00 sec)

 

root@testdb:3306 01:29:31>select  * from users;

+----+-----------+------+--------+

| id | user_name | c_id | c_note |

+----+-----------+------+--------+

|  1 | 劉備      |    2 | t1     |

|  2 | 曹操      |    1 | t2     |

|  3 | 孫 權     |    3 | t2     |

|  4 | 關羽      |    2 | t1     |

|  5 | 司馬懿    |    1 | t2     |

+----+-----------+------+--------+

5 rows in set (0.00 sec)

 

root@testdb:3306 01:29:38>commit;

 
7

查看從庫數據

 root@testdb:3307 01:40:32>select  * from  users;

+----+-----------+------+--------+

| id | user_name | c_id | c_note |

+----+-----------+------+--------+

|  1 | 劉備      |    2 | t1     |

|  2 | 曹操      |    1 | t2     |

|  3 | 孫 權     |    3 | t2     |

|  4 | 關羽      |    2 | t1     |

|  5 | 司馬懿    |    1 | t2     |

+----+-----------+------+--------+

5 rows in set (0.00 sec)

 

root@testdb:3307 01:40:35>select  * from  class;

+------+--------+--------+

| c_id | c_name | c_note |

+------+--------+--------+

|    1 | 魏     | NULL   |

|    3 | 吳     | NULL   |

|    4 | 晉     |        |

+------+--------+--------+

3 rows in set (0.00 sec)

也就是此時主從結果也是一致的。

3.2  STATEMENT格式

由於當前版本已經不支持RC+STATEMENT組合下數據的操做，不然將報以下錯誤：

Cannot execute statement: impossible to write to binary log since BINLOG_FORMAT = STATEMENT and at least one table uses a storage engine limited to row-based logging. InnoDB is limited to row-logging when transaction isolation level is READ COMMITTED or READ UNCOMMITTED.

所以單純根據步驟講解

步驟 SESSION  A SESSION B
1

mysql>set autocommit=0;

 

mysql>update users set c_note='t1' where c_id in (select  c_id from  class);

 

  
2  

mysql>set autocommit=0;

mysql>delete  from class where c_id=2;

mysql>commit;
3 mysql>update users set c_note='t2' where c_id in (select  c_id from  class);  
4 commit；  

由於binlog是按照commit時間的順序保存，所以上述步驟在binlog裏會以以下順序存儲：

binlog裏的順序 語句內容
1

delete  from class where c_id=2;

 

 
2 update users set c_note='t1' where c_id in (select  c_id from  class);
3 update users set c_note='t2' where c_id in (select  c_id from  class);

從庫經過binlog應用後，最終的結果將致使主庫的數據不同（具體案例後續安裝低版本後演示）。

於是，此種場景下很容易致使數據不同。

四、總結

經過上述的實踐，能夠發如今RR級別下，binlog爲任何格式均不會形成主從數據不一致的狀況出現，可是當低版本MySQL使用RC+STATEMENT組合時（MySQL5.1.5前只有statement格式）將會致使主從數據不一致。當前這個歷史遺漏問題以及解決，你們能夠將其設置爲RC+ROW組合的方式（例如ORACLE等數據庫隔離級別就是RC），而不是必須使用RR（會帶來更多的鎖等待），具體能夠視狀況選擇。

 

 

reapeatable read

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程