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

  對于事務(wù)的隔離級別，MySQL中默認是RR, Oracle中默認是RC,兩個事務(wù)隔離級別存在著很大的差別，而換句話說，就算是RR的事務(wù)隔離級別級別，同是關(guān)系型數(shù)據(jù)庫MySQL,SQLServer,postgreSQL也會有一些差別。所以隔離級別的部分還是值得花一些時間來總結(jié)一下。

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

   首先是初始化基礎(chǔ)數(shù)據(jù)，我們開啟兩個窗口，創(chuàng)建一個測試表，插入兩條記錄。

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

首先看下RR本身的現(xiàn)象，會話1開啟一個事務(wù)，會話2插入一條記錄，在會話1中查詢應(yīng)該還是2條數(shù)據(jù)。

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

開啟事務(wù)后，查詢當(dāng)前的數(shù)據(jù)情況。

> 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中查看數(shù)據(jù)，應(yīng)該還是2條，這也是RR本身對的含義。
會話 1:
> select *from t;
+----+-------+
| id | name  |
+----+-------+
|  1 | name1 |
|  3 | name3 |
+----+-------+
2 rows in set (0.00 sec)

我們繼續(xù)做一個update, id=4的記錄是剛剛在會話2中插入的，在此處變更，從結(jié)果來看還是產(chǎn)生了一行數(shù)據(jù)的變化，這是一個“詭異”的地方。

> Update t set name= 'name_test' where id = 4;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0
而接下來的地方就是問題的關(guān)鍵了，我們再次查詢就輸出了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的數(shù)據(jù)情況，得到的結(jié)果還是相對合理的。
會話 2:
mysql> select *from t;
+----+-------+
| id | name  |
+----+-------+
|  1 | name1 |
|  3 | name3 |
|  4 | name4 |
+----+-------+
3 rows in set (0.00 sec)

   所以這就是更新沖突的策略了，目前的MySQL在RR隔離級別下的實現(xiàn)是這樣。而按照我們預(yù)期的要求，應(yīng)該在會話1的事務(wù)內(nèi)是對會話2的變更不可見的。

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

  而關(guān)于這部分的代碼及修改可以參見

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