之前分析一個死鎖問題，發現自己對數據庫隔離級別理解還不夠深入，所以趁著這幾天假期，整理一下MySQL事務的四大隔離級別相關知識，希望對大家有幫助~

事務

什么是事務？

事務，由一個有限的數據庫操作序列構成，這些操作要么全部執行,要么全部不執行，是一個不可分割的工作單位。

假如A轉賬給B 100 元，先從A的賬戶里扣除 100 元，再在 B 的賬戶上加上 100 元。如果扣完A的100元后，還沒來得及給B加上，銀行系統異常了，最后導致A的余額減少了，B的余額卻沒有增加。所以就需要事務，將A的錢回滾回去，就是這么簡單。

事務的四大特性

原子性：事務作為一個整體被執行，包含在其中的對數據庫的操作要么全部都執行，要么都不執行。

一致性：指在事務開始之前和事務結束以后，數據不會被破壞，假如A賬戶給B賬戶轉10塊錢，不管成功與否，A和B的總金額是不變的。

隔離性：多個事務并發訪問時，事務之間是相互隔離的，一個事務不應該被其他事務干擾，多個并發事務之間要相互隔離。。

持久性：表示事務完成提交后，該事務對數據庫所作的操作更改，將持久地保存在數據庫之中。

事務并發存在的問題

事務并發執行存在什么問題呢，換句話說就是，一個事務是怎么干擾到其他事務的呢？看例子吧~

假設現在有表：

CREATE TABLE `account`(

`id`int(11) NOT NULL,

`name` varchar(255) DEFAULT NULL,

`balance`int(11) DEFAULT NULL,

PRIMARY KEY (`id`),

UNIQUE KEY `un_name_idx`(`name`) USING BTREE

) ENGINE=InnoDB DEFAULT CHARSET=utf8;

表中有數據：

臟讀（dirty read）

假設現在有兩個事務A、B：

假設現在A的余額是100，事務A正在準備查詢Jay的余額

這時候，事務B先扣減Jay的余額，扣了10

最后A 讀到的是扣減后的余額

由上圖可以發現，事務A、B交替執行，事務A被事務B干擾到了，因為事務A讀取到事務B未提交的數據,這就是臟讀。

不可重復讀（unrepeatable read）

假設現在有兩個事務A和B：

事務A先查詢Jay的余額，查到結果是100

這時候事務B 對Jay的賬戶余額進行扣減，扣去10后，提交事務

事務A再去查詢Jay的賬戶余額發現變成了90

事務A又被事務B干擾到了！在事務A范圍內，兩個相同的查詢，讀取同一條記錄，卻返回了不同的數據，這就是不可重復讀。

幻讀

假設現在有兩個事務A、B：

事務A先查詢id大于2的賬戶記錄，得到記錄id=2和id=3的兩條記錄

這時候，事務B開啟，插入一條id=4的記錄，并且提交了

事務A再去執行相同的查詢，卻得到了id=2,3,4的3條記錄了。

事務A查詢一個范圍的結果集，另一個并發事務B往這個范圍中插入/刪除了數據，并靜悄悄地提交，然后事務A再次查詢相同的范圍，兩次讀取得到的結果集不一樣了，這就是幻讀。

事務的四大隔離級別實踐

既然并發事務存在臟讀、不可重復、幻讀等問題，InnoDB實現了哪幾種事務的隔離級別應對呢？

讀未提交（Read Uncommitted）

讀已提交（Read Committed）

可重復讀（Repeatable Read）

串行化（Serializable）

讀未提交（Read Uncommitted）

想學習一個知識點，最好的方式就是實踐之。好了，我們去數據庫給它設置讀未提交隔離級別，實踐一下吧~

先把事務隔離級別設置為read uncommitted，開啟事務A，查詢id=1的數據

set session transaction isolation level read uncommitted;

begin;

select* from account where id =1;

結果如下：

這時候，另開一個窗口打開mysql，也把當前事務隔離級別設置為read uncommitted，開啟事務B，執行更新操作

set session transaction isolation level read uncommitted;

begin;

update account set balance=balance+20where id =1;

接著回事務A的窗口，再查account表id=1的數據，結果如下：

可以發現，在讀未提交（Read Uncommitted）隔離級別下，一個事務會讀到其他事務未提交的數據的，即存在臟讀問題。事務B都還沒commit到數據庫呢，事務A就讀到了，感覺都亂套了。。。實際上，讀未提交是隔離級別最低的一種。

讀已提交（READ COMMITTED）

為了避免臟讀，數據庫有了比讀未提交更高的隔離級別，即讀已提交。

把當前事務隔離級別設置為讀已提交（READ COMMITTED），開啟事務A，查詢account中id=1的數據

set session transaction isolation level read committed;

begin;

select* from account where id =1;

另開一個窗口打開mysql，也把事務隔離級別設置為read committed，開啟事務B，執行以下操作

set session transaction isolation level read committed;

begin;

update account set balance=balance+20where id =1;

接著回事務A的窗口，再查account數據，發現數據沒變：

我們再去到事務B的窗口執行commit操作：

commit;

最后回到事務A窗口查詢，發現數據變了：

由此可以得出結論，隔離級別設置為已提交讀（READ COMMITTED）時，已經不會出現臟讀問題了，當前事務只能讀取到其他事務提交的數據。但是，你站在事務A的角度想想，存在其他問題嗎？

讀已提交的隔離級別會有什么問題呢？

在同一個事務A里，相同的查詢sql，讀取同一條記錄（id=1），讀到的結果是不一樣的，即不可重復讀。所以，隔離級別設置為read committed的時候，還會存在不可重復讀的并發問題。

可重復讀（Repeatable Read）

如果你的老板要求，在同個事務中，查詢結果必須是一致的，即老板要求你解決不可重復的并發問題，怎么辦呢？老板，臣妾辦不到？來實踐一下可重復讀（Repeatable Read）這個隔離級別吧~

哈哈，步驟1、2、6的查詢結果都是一樣的，即repeatable read解決了不可重復讀問題，是不是心里美滋滋的呢，終于解決老板的難題了~

RR級別是否解決了幻讀問題呢？

再來看看網上的一個熱點問題，有關于RR級別下，是否解決了幻讀問題？我們來實踐一下：

由圖可得，步驟2和步驟6查詢結果集沒有變化，看起來RR級別是已經解決幻讀問題了~但是呢，RR級別還是存在這種現象：

其實，上圖如果事務A中，沒有 update accountsetbalance=200whereid=5;這步操作， select*fromaccountwhereid>2查詢到的結果集確實是不變，這種情況沒有幻讀問題。但是，有了update這個騷操作，同一個事務，相同的sql，查出的結果集不同，這個是符合了幻讀的定義~

這個問題，親愛的朋友，你覺得它算幻讀問題嗎？

串行化（Serializable）

前面三種數據庫隔離級別，都有一定的并發問題，現在放大招吧，實踐SERIALIZABLE隔離級別。

把事務隔離級別設置為Serializable，開啟事務A，查詢account表數據

set session transaction isolation level serializable;

select@@tx_isolation;

begin;

select* from account;

另開一個窗口打開mysql，也把事務隔離級別設置為Serializable，開啟事務B，執行插入一條數據：

set session transaction isolation level serializable;

select@@tx_isolation;

begin;

insert into account(id,name,balance) value(6,'Li',100);

執行結果如下：

由圖可得，當數據庫隔離級別設置為serializable的時候，事務B對表的寫操作，在等事務A的讀操作。其實，這是隔離級別中最嚴格的，讀寫都不允許并發。它保證了最好的安全性，性能卻是個問題~

MySql隔離級別的實現原理

實現隔離機制的方法主要有兩種：

讀寫鎖

一致性快照讀，即 MVCC

MySql使用不同的鎖策略(Locking Strategy)/MVCC來實現四種不同的隔離級別。RR、RC的實現原理跟MVCC有關，RU和Serializable跟鎖有關。

讀未提交（Read Uncommitted）

官方說法：

SELECT statements are performed in a nonlocking fashion, but a possible earlier version of a row might be used. Thus, using this isolation level, such reads are not consistent.

讀未提交，采取的是讀不加鎖原理。

事務讀不加鎖，不阻塞其他事務的讀和寫

事務寫阻塞其他事務寫，但不阻塞其他事務讀；

串行化（Serializable)

官方的說法:

InnoDB implicitly converts all plain SELECT statements to SELECT ... FOR SHARE if autocommit is disabled. If autocommit is enabled, the SELECT is its own transaction. It therefore is known to be read only and can be serialized if performed as a consistent (nonlocking) read and need not block for other transactions. (To force a plain SELECT to block if other transactions have modified the selected rows, disable autocommit.)

所有SELECT語句會隱式轉化為SELECT...FOR SHARE，即加共享鎖。

讀加共享鎖，寫加排他鎖，讀寫互斥。如果有未提交的事務正在修改某些行，所有select這些行的語句都會阻塞。

MVCC的實現原理

MVCC，中文叫多版本并發控制，它是通過讀取歷史版本的數據，來降低并發事務沖突，從而提高并發性能的一種機制。它的實現依賴于隱式字段、undo日志、快照讀&當前讀、Read View，因此，我們先來了解這幾個知識點。

隱式字段

對于InnoDB存儲引擎，每一行記錄都有兩個隱藏列DBTRXID,DBROLLPTR，如果表中沒有主鍵和非NULL唯一鍵時，則還會有第三個隱藏的主鍵列 DBROWID。

DBTRXID，記錄每一行最近一次修改（修改/更新）它的事務ID，大小為6字節；

DBROLLPTR，這個隱藏列就相當于一個指針，指向回滾段的undo日志，大小為7字節；

DBROWID，單調遞增的行ID，大小為6字節；

undo日志

事務未提交的時候，修改數據的鏡像（修改前的舊版本），存到undo日志里。以便事務回滾時，恢復舊版本數據，撤銷未提交事務數據對數據庫的影響。

undo日志是邏輯日志。可以這樣認為，當delete一條記錄時，undo log中會記錄一條對應的insert記錄，當update一條記錄時，它記錄一條對應相反的update記錄。

存儲undo日志的地方，就是回滾段。

多個事務并行操作某一行數據時，不同事務對該行數據的修改會產生多個版本，然后通過回滾指針（DBROLLPTR）連一條Undo日志鏈。

我們通過例子來看一下~

mysql> select* from account ;

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

| id | name | balance |

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

| 1| Jay| 100|

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

1 row inset(0.00 sec)

假設表accout現在只有一條記錄，插入該該記錄的事務Id為100

如果事務B（事務Id為200），對id=1的該行記錄進行更新，把balance值修改為90

事務B修改后，形成的Undo Log鏈如下：

快照讀&當前讀

快照讀：

讀取的是記錄數據的可見版本（有舊的版本），不加鎖,普通的select語句都是快照讀,如：

select* from account where id>2;

當前讀：

讀取的是記錄數據的最新版本，顯示加鎖的都是當前讀

select* from account where id>2lockin share mode;

select* from account where id>2for update;

Read View

Read View就是事務執行快照讀時，產生的讀視圖。

事務執行快照讀時，會生成數據庫系統當前的一個快照，記錄當前系統中還有哪些活躍的讀寫事務，把它們放到一個列表里。

Read View主要是用來做可見性判斷的，即判斷當前事務可見哪個版本的數據~

為了下面方便討論Read View可見性規則，先定義幾個變量

m_ids:當前系統中那些活躍的讀寫事務ID,它數據結構為一個List。

minlimitid:m_ids事務列表中，最小的事務ID

maxlimitid:m_ids事務列表中，最大的事務ID

如果DBTRXID < minlimitid，表明生成該版本的事務在生成ReadView前已經提交(因為事務ID是遞增的)，所以該版本可以被當前事務訪問。

如果DBTRXID > m_ids列表中最大的事務id，表明生成該版本的事務在生成ReadView后才生成，所以該版本不可以被當前事務訪問。

如果 minlimitid =

注意啦！！RR跟RC隔離級別，最大的區別就是：RC每次讀取數據前都生成一個ReadView，而RR只在第一次讀取數據時生成一個ReadView。

已提交讀（READ COMMITTED） 存在不可重復讀問題的分析歷程

我覺得理解一個新的知識點，最好的方法就是居于目前存在的問題/現象，去分析它的來龍去脈~ RC的實現也跟MVCC有關，RC是存在重復讀并發問題的，所以我們來分析一波RC吧，先看一下執行流程

假設現在系統里有A，B兩個事務在執行，事務ID分別為100、200，并且假設存在的老數據，插入事務ID是50哈~

事務A 先執行查詢1的操作

# 事務A，Transaction ID 100

begin;

查詢1：select* from account WHERE id = 1;

事務 B 執行更新操作，id =1記錄的undo日志鏈如下

begin;

update account set balance =balance+20where id =1;

回到事務A，執行查詢2的操作

begin;

查詢1：select* from account WHERE id = 1;

查詢2：select* from account WHERE id = 1;

查詢2執行分析：

事務A在執行到SELECT語句時，重新生成一個ReadView，因為事務B（200）在活躍，所以ReadView的m_ids列表內容就是[200]

由上圖undo日志鏈可得，最新版本的balance為1000，它的事務ID為200，在活躍事務列表里，所以當前事務（事務A）不可見。

我們繼續找下一個版本，balance為100這行記錄，事務Id為50，小于活躍事務ID列表最小記錄200，所以這個版本可見，因此，查詢2的結果，就是返回balance=100這個記錄~~

我們回到事務B，執行提交操作，這時候undo日志鏈不變

begin;

update account set balance =balance+20where id =1;

commit

再次回到事務A，執行查詢3的操作

begin;

查詢1：select* from account WHERE id = 1;

查詢2：select* from account WHERE id = 1;

查詢3：select* from account WHERE id = 1;

查詢3執行分析：

事務A在執行到SELECT語句時，重新生成一個ReadView，因為事務B（200）已經提交，不再活躍，所以ReadView的m_ids列表內容就是空的了。

所以事務A直接讀取最新記錄，讀取到balance =120這個版本的數據。

所以，這就是RC存在不可重復讀問題的過程啦~有不理解的地方可以多讀幾遍哈~

可重復讀（Repeatable Read）解決不可重復讀問題的一次分析

我們再來分析一波，RR隔離級別是如何解決不可重復讀并發問題的吧~

你可能會覺得兩個并發事務的例子太簡單了，好的！我們現在來點刺激的，開啟三個事務~

假設現在系統里有A，B，C兩個事務在執行，事務ID分別為100、200，300，存量數據插入的事務ID是50~

# 事務A，Transaction ID 100

begin;

UPDATE account SET balance = 1000 WHERE id = 1;

# 事務B，Transaction ID 200

begin; //開個事務，占坑先

這時候，account表中，id =1記錄的undo日志鏈如下：

# 事務C，Transaction ID 300

begin;

//查詢1：select * from account WHERE id = 1;

查詢1執行過程分析：

事務C在執行SELECT語句時，會先生成一個ReadView。因為事務A（100）、B（200）在活躍，所以ReadView的m_ids列表內容就是[100, 200]。

由上圖undo日志鏈可得，最新版本的balance為1000，它的事務ID為100，在活躍事務列表里，所以當前事務（事務C）不可見。

我們繼續找下一個版本，balance為100這行記錄，事務Id為50，小于活躍事務ID列表最小記錄100，所以這個版本可見，因此，查詢1的結果，就是返回balance=100這個記錄~~

接著，我們把事務A提交一下：

# 事務A，Transaction ID 100

begin;

UPDATE account SET balance = 1000 WHERE id = 1;

commit;

在事務B中，執行更新操作，把id=1的記錄balance修改為2000，更新完后，undo 日志鏈如下：

# 事務B，Transaction ID 200

begin; //開個事務，占坑先

UPDATE account SET balance = 2000 WHERE id = 1;

回到事務C，執行查詢2

# 事務C，Transaction ID 300

begin;

//查詢1：select * from account WHERE id = 1;

//查詢2：select * from account WHERE id = 1;

查詢2:執行分析：

在RR 級別下，執行查詢2的時候，因為前面ReadView已經生成過了，所以直接服用之前的ReadView，活躍事務列表為[100,200].

由上圖undo日志鏈可得，最新版本的balance為2000，它的事務ID為200，在活躍事務列表里，所以當前事務（事務C）不可見。

我們繼續找下一個版本，balance為1000這行記錄，事務Id為100,也在活躍事務列表里，所以當前事務（事務C）不可見。

繼續找下一個版本，balance為100這行記錄，事務Id為50，小于活躍事務ID列表最小記錄100，所以這個版本可見，因此，查詢2的結果，也是返回balance=100這個記錄~~

鎖相關概念補充（附）：

共享鎖與排他鎖

InnoDB 實現了標準的行級鎖，包括兩種：共享鎖（簡稱 s 鎖）、排它鎖（簡稱 x 鎖）。

共享鎖（S鎖）：允許持鎖事務讀取一行。

排他鎖（X鎖）：允許持鎖事務更新或者刪除一行。

如果事務 T1 持有行 r 的 s 鎖，那么另一個事務 T2 請求 r 的鎖時，會做如下處理：

T2 請求 s 鎖立即被允許，結果 T1 T2 都持有 r 行的 s 鎖

T2 請求 x 鎖不能被立即允許

如果 T1 持有 r 的 x 鎖，那么 T2 請求 r 的 x、s 鎖都不能被立即允許，T2 必須等待T1釋放 x 鎖才可以，因為X鎖與任何的鎖都不兼容。

記錄鎖（Record Locks）

記錄鎖是最簡單的行鎖，僅僅鎖住一行。如：SELECT c1 FROM t WHERE c1=10FOR UPDATE

記錄鎖永遠都是加在索引上的，即使一個表沒有索引，InnoDB也會隱式的創建一個索引，并使用這個索引實施記錄鎖。

會阻塞其他事務對其插入、更新、刪除

記錄鎖的事務數據（關鍵詞：lock_mode X locks rec butnotgap），記錄如下：

RECORD LOCKS space id 58 page no3 n bits 72 index `PRIMARY` of table `test`.`t`

trx id 10078 lock_mode X locks rec but not gap

Recordlock, heap no2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0

0: len 4; hex 8000000a; asc ;;

1: len 6; hex 00000000274f; asc 'O;;

2: len 7; hex b60000019d0110; asc ;;

間隙鎖（Gap Locks）

間隙鎖是一種加在兩個索引之間的鎖，或者加在第一個索引之前，或最后一個索引之后的間隙。

使用間隙鎖鎖住的是一個區間，而不僅僅是這個區間中的每一條數據。

間隙鎖只阻止其他事務插入到間隙中，他們不阻止其他事務在同一個間隙上獲得間隙鎖，所以 gap x lock 和 gap s lock 有相同的作用。

Next-Key Locks

Next-key鎖是記錄鎖和間隙鎖的組合，它指的是加在某條記錄以及這條記錄前面間隙上的鎖。

RC級別存在幻讀分析

因為RC是存在幻讀問題的，所以我們先切到RC隔離級別，分析一波~

假設account表有4條數據。

開啟事務A，執行當前讀，查詢id>2的所有記錄。

再開啟事務B，插入id=5的一條數據。

事務B插入數據成功后，再修改id=3的記錄

回到事務A,再次執行id>2的當前讀查詢

事務B可以插入id=5的數據，卻更新不了id=3的數據，陷入阻塞。證明事務A在執行當前讀的時候在id =3和id=4這兩條記錄上加了鎖，但是并沒有對 id > 2 這個范圍加鎖~

事務B陷入阻塞后，切回事務A執行當前讀操作時，死鎖出現。因為事務B在 insert 的時候，會在新記錄（id=5）上加鎖，所以事務A再次執行當前讀，想獲取id> 2 的記錄，就需要在 id=3,4,5 這3條記錄上加鎖，但是 id = 5這條記錄已經被事務B 鎖住了，于是事務A被事務B阻塞，同時事務B還在等待 事務A釋放 id = 3上的鎖，最終產生了死鎖。

因此，我們可以發現，RC隔離級別下，加鎖的select, update, delete等語句，使用的是記錄鎖，其他事務的插入依然可以執行，因此會存在幻讀~

RR 級別解決幻讀分析

因為RR是解決幻讀問題的，怎么解決的呢，分析一波吧~

假設account表有4條數據，RR級別。

開啟事務A，執行當前讀，查詢id>2的所有記錄。

再開啟事務B，插入id=5的一條數據。

可以發現，事務B執行插入操作時，阻塞了~因為事務A在執行select ... lock in share mode的時候，不僅在 id = 3,4 這2條記錄上加了鎖，而且在id > 2 這個范圍上也加了間隙鎖。

因此，我們可以發現，RR隔離級別下，加鎖的select, update, delete等語句，會使用間隙鎖+ 臨鍵鎖，鎖住索引記錄之間的范圍，避免范圍間插入記錄，以避免產生幻影行記錄。

原文標題：一文徹底讀懂 MySQL 事務的四大隔離級別

文章出處：【微信公眾號：數據分析與開發】歡迎添加關注！文章轉載請注明出處。

責任編輯：haq