MySQL事務隔離級別學習

1. MySQL事務隔離級別學習筆記

1.1. 隔離級別

READ UNCOMMITTED 未提交讀

在READ UNCOMMITTED級別，事務中的修改，即使沒有提交，對其他事務也都是可見的。事務可以讀取未提交的數據，這也被稱作臟讀。這個級別會導致很多問題，從性能上來說，READ UNCOMMITTED不會比其他的級別好太多，但確缺乏其他級別的很多好處，除非真的有必要的理由，在實際應用中一般很少使用。
READ COMMITED 提交讀

大多數數據庫系統的默認隔離級別是 READ COMMITED（但mysql不是）。READ COMMITED滿足前面提到的隔離性簡單定義：一個事務開始時，只能看見已經提交的事務所做的修改。換句話說，一個事務從開始直到提交之前，所做的任何修改對其他事務都是不可見的。這個級別有時候也叫做不可重復讀，因為兩次執行同樣的查詢，可能會得到不一樣的結果。

這里的原因是，在兩次執行同樣的查詢中間，可能由其他事務修改了影響查詢結果的數據。在 Read Commited級別下，會發生這種情況。
REPEATABLE READ 可重復讀

MySQL的默認事務隔離級別。
REPEATABLE READ解決了臟讀的問題。該級別保證了在同一個事務中多次讀取同樣的記錄的結果是一致的。但是理論上，可重復讀隔離級別還是無法解決另一個幻讀的問題。所謂幻讀，指的是當某個事務在讀取某個范圍內的記錄時，另外一個事務又在該范圍內插入了新的記錄，當之前的事務再次讀取該范圍的記錄時，會產生幻行。InnoDB存儲引擎通過多版本并發控制（MVCC）解決了幻讀的問題。

在一個事務未提交前，多次查詢相同的查詢，都會返回相同的結果。即使在此期間有其他事務已提交了影響該查詢的數據。
SERIALIZABLE 可串行化

SERIALIZABLE 是最高的隔離級別。它通過強事務串行執行，避免了前面說的幻讀的問題。簡單來說，SERIALIZABLE會在曲度的每一行數據都加上鎖，所以可能導致大量的超時和鎖爭用的問題。實際應用中也很少用到這個隔離級別，只有在非常需要確保數據一致性而且可以接受沒有并發的情況下，才考慮使用該級別。

1.2. 實驗

上面是摘自《高性能MySQL》一書，光這么看，可能也理解不到多少東西，不如直接做實驗親身體驗一下，加深理解。

我們先簡單創建一個表 users，結構如下：

+------------+------------------+------+-----+-------------------+----------------+
| Field      | Type             | Null | Key | Default           | Extra          |
+------------+------------------+------+-----+-------------------+----------------+
| id         | int(11) unsigned | NO   | PRI | <null>            | auto_increment |
| name       | varchar(50)      | NO   |     |                   |                |
| created_at | datetime         | NO   |     | CURRENT_TIMESTAMP |                |
| updated_at | datetime         | NO   |     | CURRENT_TIMESTAMP |                |
| deleted_at | datetime         | YES  |     | <null>            |                |
+------------+------------------+------+-----+-------------------+----------------+

實現插入三條數據：

+----+-------------+---------------------+---------------------+------------+
| id | name        | created_at          | updated_at          | deleted_at |
+----+-------------+---------------------+---------------------+------------+
| 1  | coolcao2018 | 2018-05-28 12:48:43 | 2018-05-28 12:48:43 | <null>     |
| 2  | tom         | 2018-05-28 13:24:28 | 2018-05-28 13:24:28 | <null>     |
| 3  | lili        | 2018-05-31 08:54:28 | 2018-05-31 08:54:28 | <null>     |
+----+-------------+---------------------+---------------------+------------+

然后打開兩個終端，A和B分別表示兩個用戶同時在操作。

1.2.1. READ UNCOMMITTED 未提交讀

對于用戶A，操作：

mysql root@localhost:test> set session transaction isolation level read uncommitted;
mysql root@localhost:test> start transaction;
mysql root@localhost:test> select * from users;

+----+-------------+---------------------+---------------------+------------+
| id | name        | created_at          | updated_at          | deleted_at |
+----+-------------+---------------------+---------------------+------------+
| 1  | coolcao2018 | 2018-05-28 12:48:43 | 2018-05-28 12:48:43 | <null>     |
| 2  | tom         | 2018-05-28 13:24:28 | 2018-05-28 13:24:28 | <null>     |
| 3  | lili        | 2018-05-31 08:54:28 | 2018-05-31 08:54:28 | <null>     |
+----+-------------+---------------------+---------------------+------------+

然后，用戶B操作，

mysql root@localhost:test> set session transaction isolation level read uncommitted;
mysql root@localhost:test> start transaction;
mysql root@localhost:test> update users set name='coolcao' where id=1;

此時，用戶B并未提交事務，用戶A進行查詢操作看看：

mysql root@localhost:test> select * from users;

+----+---------+---------------------+---------------------+------------+
| id | name    | created_at          | updated_at          | deleted_at |
+----+---------+---------------------+---------------------+------------+
| 1  | coolcao | 2018-05-28 12:48:43 | 2018-05-28 12:48:43 | <null>     |
| 2  | tom     | 2018-05-28 13:24:28 | 2018-05-28 13:24:28 | <null>     |
| 3  | lili    | 2018-05-31 08:54:28 | 2018-05-31 08:54:28 | <null>     |
+----+---------+---------------------+---------------------+------------+

從整個過程來看，用戶B還并未提交事務，但是A卻已經能夠直接讀到B的更新。

從上面實驗結果來看，不難理解上面對于 READ UNCOMMITTED級別的描述：在READ UNCOMMITTED級別，事務中的修改，即使沒有提交，對其他事務也都是可見的。

1.2.2. READ COMMITTED 提交讀

同時將A，B兩個終端的事務級別設置為 read committed:

 // 在A，B兩個終端都執行
 set session transaction isolation level read committed;

對于A，我們開啟一個事務，然后更新一下數據，但并不提交事務：

mysql root@localhost:test>  set session transaction isolation level read committed;
mysql root@localhost:test> start transaction;
mysql root@localhost:test> select * from users;

+----+---------+---------------------+---------------------+------------+
| id | name    | created_at          | updated_at          | deleted_at |
+----+---------+---------------------+---------------------+------------+
| 1  | coolcao | 2018-05-28 12:48:43 | 2018-05-28 12:48:43 | <null>     |
| 2  | tom     | 2018-05-28 13:24:28 | 2018-05-28 13:24:28 | <null>     |
| 3  | lili    | 2018-05-31 08:54:28 | 2018-05-31 08:54:28 | <null>     |
+----+---------+---------------------+---------------------+------------+

mysql root@localhost:test> update users set name='coolcao222' where id=1;
mysql root@localhost:test> select * from users;

+----+------------+---------------------+---------------------+------------+
| id | name       | created_at          | updated_at          | deleted_at |
+----+------------+---------------------+---------------------+------------+
| 1  | coolcao222 | 2018-05-28 12:48:43 | 2018-05-28 12:48:43 | <null>     |
| 2  | tom        | 2018-05-28 13:24:28 | 2018-05-28 13:24:28 | <null>     |
| 3  | lili       | 2018-05-31 08:54:28 | 2018-05-31 08:54:28 | <null>     |
+----+------------+---------------------+---------------------+------------+

然后，在B終端，開啟另外一個事務，進行數據查詢：

mysql root@localhost:test> set session transaction isolation level read committed;
mysql root@localhost:test> start transaction;
mysql root@localhost:test> select * from users;

+----+---------+---------------------+---------------------+------------+
| id | name    | created_at          | updated_at          | deleted_at |
+----+---------+---------------------+---------------------+------------+
| 1  | coolcao | 2018-05-28 12:48:43 | 2018-05-28 12:48:43 | <null>     |
| 2  | tom     | 2018-05-28 13:24:28 | 2018-05-28 13:24:28 | <null>     |
| 3  | lili    | 2018-05-31 08:54:28 | 2018-05-31 08:54:28 | <null>     |
+----+---------+---------------------+---------------------+------------+

然后，將A事務提交：

commit;

這時，再在B查詢：

mysql root@localhost:test> select * from users;

+----+------------+---------------------+---------------------+------------+
| id | name       | created_at          | updated_at          | deleted_at |
+----+------------+---------------------+---------------------+------------+
| 1  | coolcao222 | 2018-05-28 12:48:43 | 2018-05-28 12:48:43 | <null>     |
| 2  | tom        | 2018-05-28 13:24:28 | 2018-05-28 13:24:28 | <null>     |
| 3  | lili       | 2018-05-31 08:54:28 | 2018-05-31 08:54:28 | <null>     |
+----+------------+---------------------+---------------------+------------+

從結果來看，也不難理解 read committed級別，對于一個事務，只能讀取到當前事務的數據和其他已經提交的事務的數據，對于其他未提交事務的數據，讀不到。
而且，從上面的實驗結果中，我們也看到了，會話B在會話A提交事務前后查詢的結果并不一致，這也就是上面所說的，不可重復讀。

1.2.3. REPEATABLE READ 可重復讀

我們將會話A設置為REPEATABLE READ :

mysql root@localhost:test> set session transaction isolation level repeatable read;
mysql root@localhost:test> start transaction;
mysql root@localhost:test> select * from users;

+----+---------+---------------------+---------------------+------------+
| id | name    | created_at          | updated_at          | deleted_at |
+----+---------+---------------------+---------------------+------------+
| 1  | coolcao | 2018-08-10 15:21:02 | 2018-08-10 15:21:02 | <null>     |
| 2  | tom     | 2018-08-10 15:21:07 | 2018-08-10 15:21:07 | <null>     |
| 3  | lili    | 2018-08-10 15:21:11 | 2018-08-10 15:21:11 | <null>     |
+----+---------+---------------------+---------------------+------------+

此時，我們在B終端插入一條數據：

mysql root@localhost:test> insert into users (id,name) values (4,'coco');
mysql root@localhost:test> commit;
mysql root@localhost:test> select * from users;

+----+---------+---------------------+---------------------+------------+
| id | name    | created_at          | updated_at          | deleted_at |
+----+---------+---------------------+---------------------+------------+
| 1  | coolcao | 2018-08-10 15:21:02 | 2018-08-10 15:21:02 | <null>     |
| 2  | tom     | 2018-08-10 15:21:07 | 2018-08-10 15:21:07 | <null>     |
| 3  | lili    | 2018-08-10 15:21:11 | 2018-08-10 15:21:11 | <null>     |
| 4  | coco    | 2018-08-10 15:23:50 | 2018-08-10 15:23:50 | <null>     |
+----+---------+---------------------+---------------------+------------+

在終端B中，插入一條記錄，并提交，這時id=4的用戶已經被插入到數據庫。

此時，再回到終端A，查詢：

mysql root@localhost:test> select * from users;

+----+---------+---------------------+---------------------+------------+
| id | name    | created_at          | updated_at          | deleted_at |
+----+---------+---------------------+---------------------+------------+
| 1  | coolcao | 2018-08-10 15:21:02 | 2018-08-10 15:21:02 | <null>     |
| 2  | tom     | 2018-08-10 15:21:07 | 2018-08-10 15:21:07 | <null>     |
| 3  | lili    | 2018-08-10 15:21:11 | 2018-08-10 15:21:11 | <null>     |
+----+---------+---------------------+---------------------+------------+

哎，查詢的結果中，沒有B剛插入的id=4的用戶，這也就是說該級別的事務隔離，保證了在同一個事務中多次讀取同樣的記錄的結果是一致的。這時，我們在A中插入一條記錄：

mysql root@localhost:test> insert into users (id,name) values (4,'coco');
(1062, u"Duplicate entry '4' for key 'PRIMARY'")

哎，這個時候，數據庫報錯了，提示主鍵重復。明明我在這個事務中，查詢的數據只有1,2,3，為什么插入4的時候提示主鍵沖突呢？是發生幻覺了么？是的，發生“幻讀”了。由于REPEATABLE READ級別的隔離，在一個事務中，多次讀取同樣記錄的結果是一致的，在這多次讀取之間，被別的事務插入了新的數據，這時前事務再插入數據，必然會導致錯誤。

在一個事務未提交前，多次查詢相同的查詢，返回的結果是相同的，即使在此期間，其他事務已經提交了影響該查詢的數據。

1.2.4. SERIALIZABLE 可串行化

我們將A，B同時設置為SERIALIZABLE, 然后在A開啟是個事務，做一個簡單查詢：

mysql root@localhost:test> set session transaction isolation level serializable;
mysql root@localhost:test> start transaction;
mysql root@localhost:test> select * from users where id<10;

+----+---------+---------------------+---------------------+------------+
| id | name    | created_at          | updated_at          | deleted_at |
+----+---------+---------------------+---------------------+------------+
| 1  | coolcao | 2018-08-10 15:21:02 | 2018-08-10 15:21:02 | <null>     |
| 2  | tom     | 2018-08-10 15:21:07 | 2018-08-10 15:21:07 | <null>     |
| 3  | lili    | 2018-08-10 15:21:11 | 2018-08-10 15:21:11 | <null>     |
| 4  | coco    | 2018-08-10 15:23:50 | 2018-08-10 15:23:50 | <null>     |
| 5  | juli    | 2018-08-10 15:31:32 | 2018-08-10 15:31:32 | <null>     |
+----+---------+---------------------+---------------------+------------+

此時，A事務并未提交，然后在B再開啟一個事務，進行插入操作：

mysql root@localhost:test> set session transaction isolation level serializable;
mysql root@localhost:test> start transaction;
mysql root@localhost:test> insert into users (id,name) values (6,'kate');
(1205, u'Lock wait timeout exceeded; try restarting transaction')

你會發現，哎我去，B事務被掛住了，然后過了一段時間，提示了錯誤 (1205, u'Lock wait timeout exceeded; try restarting transaction')，說等待鎖超時。
是的，在串行化級別，會在讀取的每一行數據都加上鎖，也就是說，上面A事務在讀取時，已經加了鎖，此時B事務在插入操作時，得等待鎖的放開，時間一長，A鎖未放開，B就報錯了。
從實驗中可以看出，可串行化級別，由于要保證避免幻讀而加了鎖導致效率以及可能會觸發的等待鎖超時等錯誤，實際應用中，該級別的事務隔離也很少使用。

對照著實驗結果，來理解上面四個隔離級別，就容易理解了。

?著作權歸作者所有,轉載或內容合作請聯系作者

人面猴
序言：七十年代末，一起剝皮案震驚了整個濱河市，隨后出現的幾起案子，更是在濱河造成了極大的恐慌，老刑警劉巖，帶你破解...
沈念sama閱讀 227,663評論 6贊 531
死咒
序言：濱河連續發生了三起死亡事件，死亡現場離奇詭異，居然都是意外死亡，警方通過查閱死者的電腦和手機，發現死者居然都...
沈念sama閱讀 98,125評論 3贊 414
救了他兩次的神仙讓他今天三更去死
文/潘曉璐我一進店門，熙熙樓的掌柜王于貴愁眉苦臉地迎上來，“玉大人，你說我怎么就攤上這事。” “怎么了？”我有些...
開封第一講書人閱讀 175,506評論 0贊 373
道士緝兇錄：失蹤的賣姜人
文/不壞的土叔我叫張陵，是天一觀的道長。經常有香客問我，道長，這世上最難降的妖魔是什么？我笑而不...
開封第一講書人閱讀 62,614評論 1贊 307
?港島之戀（遺憾婚禮）
正文為了忘掉前任，我火速辦了婚禮，結果婚禮上，老公的妹妹穿的比我還像新娘。我一直安慰自己，他們只是感情好，可當我...
茶點故事閱讀 71,402評論 6贊 404
惡毒庶女頂嫁案：這布局不是一般人想出來的
文/花漫我一把揭開白布。她就那樣靜靜地躺著，像睡著了一般。火紅的嫁衣襯著肌膚如雪。梳的紋絲不亂的頭發上，一...
開封第一講書人閱讀 54,934評論 1贊 321
城市分裂傳說
那天，我揣著相機與錄音，去河邊找鬼。笑死，一個胖子當著我的面吹牛，可吹牛的內容都是我干的。我是一名探鬼主播，決...
沈念sama閱讀 43,021評論 3贊 440
雙鴛鴦連環套：你想象不到人心有多黑
文/蒼蘭香墨我猛地睜開眼，長吁一口氣：“原來是場噩夢啊……” “哼！你這毒婦竟也來了？” 一聲冷哼從身側響起，我...
開封第一講書人閱讀 42,168評論 0贊 287
萬榮殺人案實錄
序言：老撾萬榮一對情侶失蹤，失蹤者是張志新（化名）和其女友劉穎，沒想到半個月后，有當地人在樹林里發現了一具尸體，經...
沈念sama閱讀 48,690評論 1贊 333
?護林員之死
正文獨居荒郊野嶺守林人離奇死亡，尸身上長有42處帶血的膿包…… 初始之章·張勛以下內容為張勛視角年9月15日...
茶點故事閱讀 40,596評論 3贊 354
?白月光啟示錄
正文我和宋清朗相戀三年，在試婚紗的時候發現自己被綠了。大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
茶點故事閱讀 42,784評論 1贊 369
活死人
序言：一個原本活蹦亂跳的男人離奇死亡，死狀恐怖，靈堂內的尸體忽然破棺而出，到底是詐尸還是另有隱情，我是刑警寧澤，帶...
沈念sama閱讀 38,288評論 5贊 357
?日本核電站爆炸內幕
正文年R本政府宣布，位于F島的核電站，受9級特大地震影響，放射性物質發生泄漏。R本人自食惡果不足惜，卻給世界環境...
茶點故事閱讀 44,027評論 3贊 347
男人毒藥：我在死后第九天來索命
文/蒙蒙一、第九天我趴在偏房一處隱蔽的房頂上張望。院中可真熱鬧，春花似錦、人聲如沸。這莊子的主人今日做“春日...
開封第一講書人閱讀 34,404評論 0贊 25
一樁弒父案，背后竟有這般陰謀
文/蒼蘭香墨我抬頭看了看天上的太陽。三九已至，卻和暖如春，著一層夾襖步出監牢的瞬間，已是汗流浹背。一陣腳步聲響...
開封第一講書人閱讀 35,662評論 1贊 280
情欲美人皮
我被黑心中介騙來泰國打工，沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留，地道東北人。一個月前我還...
沈念sama閱讀 51,398評論 3贊 390
代替公主和親
正文我出身青樓，卻偏偏與公主長得像，于是被迫代替她去往敵國和親。傳聞我的和親對象是個殘疾皇子，可洞房花燭夜當晚...
茶點故事閱讀 47,743評論 2贊 370

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美国产综合欧美视频

MySQL事務隔離級別學習

MySQL事務隔離級別學習

1. MySQL事務隔離級別學習筆記

1.1. 隔離級別

1.2. 實驗

1.2.1. READ UNCOMMITTED 未提交讀

1.2.2. READ COMMITTED 提交讀

1.2.3. REPEATABLE READ 可重復讀

1.2.4. SERIALIZABLE 可串行化

推薦閱讀更多精彩內容

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美 国产 综合 欧美 视频

MySQL事務隔離級別學習

1. MySQL事務隔離級別學習筆記

1.1. 隔離級別

1.2. 實驗

1.2.1. READ UNCOMMITTED 未提交讀

1.2.2. READ COMMITTED 提交讀

1.2.3. REPEATABLE READ 可重復讀

1.2.4. SERIALIZABLE 可串行化

推薦閱讀更多精彩內容

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美国产综合欧美视频