MySQL RR隔離級別的更新衝突策略

  對於事務的隔離級別，MySQL中預設是RR, Oracle中預設是RC,兩個事務隔離級別存在著很大的差別，而換句話說，就算是RR的事務隔離級別級別，同是關係型資料庫MySQL,SQLServer,postgreSQL也會有一些差別。所以隔離級別的部分還是值得花一些時間來總結一下。

   之前看到過丁奇大師的一篇文章，是分析InnoDB的在隔離級別RR下的一個“詭異”現象。讀來受益匪淺，丁大師不光明理而且還能改動程式碼解決問題，實在佩服，我在自己的環境中也做了一些簡單的測試和分析。

   首先是初始化基礎資料，我們開啟兩個視窗，建立一個測試表，插入兩條記錄。

create table t (id int not null, name varchar(10) ) engine=innodb ;
insert into t values(1,'name1'),(3,'name3');
   整個過程雖然是兩個視窗，但是操作是一個序列的過程。

首先看下RR本身的現象，會話1開啟一個事務，會話2插入一條記錄，在會話1中查詢應該還是2條資料。

#會話 1
> begin;
Query OK, 0 rows affected (0.00 sec)

開啟事務後，查詢當前的資料情況。

> select *from t;
+----+-------+
| id | name  |
+----+-------+
|  1 | name1 |
|  3 | name3 |
+----+-------+
2 rows in set (0.00 sec)

會話 2:

會話2插入一條記錄，預設提交。
> insert into t values(4,'name4');
Query OK, 1 row affected (0.00 sec)

這個過程中，如果在會話1中檢視資料，應該還是2條，這也是RR本身對的含義。
會話 1:
> select *from t;
+----+-------+
| id | name  |
+----+-------+
|  1 | name1 |
|  3 | name3 |
+----+-------+
2 rows in set (0.00 sec)

我們繼續做一個update, id=4的記錄是剛剛在會話2中插入的，在此處變更，從結果來看還是產生了一行資料的變化，這是一個“詭異”的地方。

> Update t set name= 'name_test' where id = 4;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0
而接下來的地方就是問題的關鍵了，我們再次查詢就輸出了3行記錄，原來id=4,name='name4'的記錄在會話1裡面被修改成了id=4,name='name_test'

> select *from t;
+----+-----------+
| id | name      |
+----+-----------+
|  1 | name1     |
|  3 | name3     |
|  4 | name_test |
+----+-----------+
3 rows in set (0.00 sec)

這個時候如果檢視會話2的資料情況，得到的結果還是相對合理的。
會話 2:
mysql> select *from t;
+----+-------+
| id | name  |
+----+-------+
|  1 | name1 |
|  3 | name3 |
|  4 | name4 |
+----+-------+
3 rows in set (0.00 sec)

   所以這就是更新衝突的策略了，目前的MySQL在RR隔離級別下的實現是這樣。而按照我們預期的要求，應該在會話1的事務內是對會話2的變更不可見的。

   這一點上，在5.7中的結果也是如此，在5.1的版本中的update的輸出效果會有一些差別。

  而關於這部分的程式碼及修改可以參見

http://dinglin.iteye.com/blog/804655