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

事務(wù)

什么是事務(wù)？

事務(wù)，由一個有限的數(shù)據(jù)庫操作序列構(gòu)成，這些操作要么全部執(zhí)行,要么全部不執(zhí)行，是一個不可分割的工作單位。

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

事務(wù)的四大特性

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

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

隔離性：多個事務(wù)并發(fā)訪問時，事務(wù)之間是相互隔離的，一個事務(wù)不應(yīng)該被其他事務(wù)干擾，多個并發(fā)事務(wù)之間要相互隔離。。

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

事務(wù)并發(fā)存在的問題

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

假設(shè)現(xiàn)在有表：

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;

表中有數(shù)據(jù)：

臟讀（dirty read）

假設(shè)現(xiàn)在有兩個事務(wù)A、B：

假設(shè)現(xiàn)在A的余額是100，事務(wù)A正在準(zhǔn)備查詢Jay的余額

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

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

由上圖可以發(fā)現(xiàn)，事務(wù)A、B交替執(zhí)行，事務(wù)A被事務(wù)B干擾到了，因為事務(wù)A讀取到事務(wù)B未提交的數(shù)據(jù),這就是臟讀。

不可重復(fù)讀（unrepeatable read）

假設(shè)現(xiàn)在有兩個事務(wù)A和B：

事務(wù)A先查詢Jay的余額，查到結(jié)果是100

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

事務(wù)A再去查詢Jay的賬戶余額發(fā)現(xiàn)變成了90

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

幻讀

假設(shè)現(xiàn)在有兩個事務(wù)A、B：

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

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

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

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

事務(wù)的四大隔離級別實踐

既然并發(fā)事務(wù)存在臟讀、不可重復(fù)、幻讀等問題，InnoDB實現(xiàn)了哪幾種事務(wù)的隔離級別應(yīng)對呢？

讀未提交（Read Uncommitted）

讀已提交（Read Committed）

可重復(fù)讀（Repeatable Read）

串行化（Serializable）

讀未提交（Read Uncommitted）

想學(xué)習(xí)一個知識點，最好的方式就是實踐之。好了，我們?nèi)?shù)據(jù)庫給它設(shè)置讀未提交隔離級別，實踐一下吧~

先把事務(wù)隔離級別設(shè)置為read uncommitted，開啟事務(wù)A，查詢id=1的數(shù)據(jù)

set session transaction isolation level read uncommitted;

begin;

select* from account where id =1;

結(jié)果如下：

這時候，另開一個窗口打開mysql，也把當(dāng)前事務(wù)隔離級別設(shè)置為read uncommitted，開啟事務(wù)B，執(zhí)行更新操作

set session transaction isolation level read uncommitted;

begin;

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

接著回事務(wù)A的窗口，再查account表id=1的數(shù)據(jù)，結(jié)果如下：

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

讀已提交（READ COMMITTED）

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

把當(dāng)前事務(wù)隔離級別設(shè)置為讀已提交（READ COMMITTED），開啟事務(wù)A，查詢account中id=1的數(shù)據(jù)

set session transaction isolation level read committed;

begin;

select* from account where id =1;

另開一個窗口打開mysql，也把事務(wù)隔離級別設(shè)置為read committed，開啟事務(wù)B，執(zhí)行以下操作

set session transaction isolation level read committed;

begin;

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

接著回事務(wù)A的窗口，再查account數(shù)據(jù)，發(fā)現(xiàn)數(shù)據(jù)沒變：

我們再去到事務(wù)B的窗口執(zhí)行commit操作：

commit;

最后回到事務(wù)A窗口查詢，發(fā)現(xiàn)數(shù)據(jù)變了：

由此可以得出結(jié)論，隔離級別設(shè)置為已提交讀（READ COMMITTED）時，已經(jīng)不會出現(xiàn)臟讀問題了，當(dāng)前事務(wù)只能讀取到其他事務(wù)提交的數(shù)據(jù)。但是，你站在事務(wù)A的角度想想，存在其他問題嗎？

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

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

可重復(fù)讀（Repeatable Read）

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

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

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

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

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

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

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

串行化（Serializable）

前面三種數(shù)據(jù)庫隔離級別，都有一定的并發(fā)問題，現(xiàn)在放大招吧，實踐SERIALIZABLE隔離級別。

把事務(wù)隔離級別設(shè)置為Serializable，開啟事務(wù)A，查詢account表數(shù)據(jù)

set session transaction isolation level serializable;

select@@tx_isolation;

begin;

select* from account;

另開一個窗口打開mysql，也把事務(wù)隔離級別設(shè)置為Serializable，開啟事務(wù)B，執(zhí)行插入一條數(shù)據(jù)：

set session transaction isolation level serializable;

select@@tx_isolation;

begin;

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

執(zhí)行結(jié)果如下：

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

MySql隔離級別的實現(xiàn)原理

實現(xiàn)隔離機制的方法主要有兩種：

讀寫鎖

一致性快照讀，即 MVCC

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

讀未提交（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.

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

事務(wù)讀不加鎖，不阻塞其他事務(wù)的讀和寫

事務(wù)寫阻塞其他事務(wù)寫，但不阻塞其他事務(wù)讀；

串行化（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語句會隱式轉(zhuǎn)化為SELECT...FOR SHARE，即加共享鎖。

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

MVCC的實現(xiàn)原理

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

隱式字段

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

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

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

DBROWID，單調(diào)遞增的行ID，大小為6字節(jié)；

undo日志

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

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

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

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

我們通過例子來看一下~

mysql> select* from account ;

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

| id | name | balance |

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

| 1| Jay| 100|

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

1 row inset(0.00 sec)

假設(shè)表accout現(xiàn)在只有一條記錄，插入該該記錄的事務(wù)Id為100

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

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

快照讀&當(dāng)前讀

快照讀：

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

select* from account where id>2;

當(dāng)前讀：

讀取的是記錄數(shù)據(jù)的最新版本，顯示加鎖的都是當(dāng)前讀

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

select* from account where id>2for update;

Read View

Read View就是事務(wù)執(zhí)行快照讀時，產(chǎn)生的讀視圖。

事務(wù)執(zhí)行快照讀時，會生成數(shù)據(jù)庫系統(tǒng)當(dāng)前的一個快照，記錄當(dāng)前系統(tǒng)中還有哪些活躍的讀寫事務(wù)，把它們放到一個列表里。

Read View主要是用來做可見性判斷的，即判斷當(dāng)前事務(wù)可見哪個版本的數(shù)據(jù)~

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

m_ids:當(dāng)前系統(tǒng)中那些活躍的讀寫事務(wù)ID,它數(shù)據(jù)結(jié)構(gòu)為一個List。

minlimitid:m_ids事務(wù)列表中，最小的事務(wù)ID

maxlimitid:m_ids事務(wù)列表中，最大的事務(wù)ID

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

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

如果 minlimitid =

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

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

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

假設(shè)現(xiàn)在系統(tǒng)里有A，B兩個事務(wù)在執(zhí)行，事務(wù)ID分別為100、200，并且假設(shè)存在的老數(shù)據(jù)，插入事務(wù)ID是50哈~

事務(wù)A 先執(zhí)行查詢1的操作

# 事務(wù)A，Transaction ID 100

begin;

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

事務(wù) B 執(zhí)行更新操作，id =1記錄的undo日志鏈如下

begin;

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

回到事務(wù)A，執(zhí)行查詢2的操作

begin;

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

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

查詢2執(zhí)行分析：

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

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

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

我們回到事務(wù)B，執(zhí)行提交操作，這時候undo日志鏈不變

begin;

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

commit

再次回到事務(wù)A，執(zhí)行查詢3的操作

begin;

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

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

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

查詢3執(zhí)行分析：

事務(wù)A在執(zhí)行到SELECT語句時，重新生成一個ReadView，因為事務(wù)B（200）已經(jīng)提交，不再活躍，所以ReadView的m_ids列表內(nèi)容就是空的了。

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

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

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

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

你可能會覺得兩個并發(fā)事務(wù)的例子太簡單了，好的！我們現(xiàn)在來點刺激的，開啟三個事務(wù)~

假設(shè)現(xiàn)在系統(tǒng)里有A，B，C兩個事務(wù)在執(zhí)行，事務(wù)ID分別為100、200，300，存量數(shù)據(jù)插入的事務(wù)ID是50~

# 事務(wù)A，Transaction ID 100

begin;

UPDATE account SET balance = 1000 WHERE id = 1;

# 事務(wù)B，Transaction ID 200

begin; //開個事務(wù)，占坑先

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

# 事務(wù)C，Transaction ID 300

begin;

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

查詢1執(zhí)行過程分析：

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

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

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

接著，我們把事務(wù)A提交一下：

# 事務(wù)A，Transaction ID 100

begin;

UPDATE account SET balance = 1000 WHERE id = 1;

commit;

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

# 事務(wù)B，Transaction ID 200

begin; //開個事務(wù)，占坑先

UPDATE account SET balance = 2000 WHERE id = 1;

回到事務(wù)C，執(zhí)行查詢2

# 事務(wù)C，Transaction ID 300

begin;

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

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

查詢2:執(zhí)行分析：

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

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

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

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

鎖相關(guān)概念補充（附）：

共享鎖與排他鎖

InnoDB 實現(xiàn)了標(biāo)準(zhǔn)的行級鎖，包括兩種：共享鎖（簡稱 s 鎖）、排它鎖（簡稱 x 鎖）。

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

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

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

T2 請求 s 鎖立即被允許，結(jié)果 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也會隱式的創(chuàng)建一個索引，并使用這個索引實施記錄鎖。

會阻塞其他事務(wù)對其插入、更新、刪除

記錄鎖的事務(wù)數(shù)據(jù)（關(guān)鍵詞：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）

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

使用間隙鎖鎖住的是一個區(qū)間，而不僅僅是這個區(qū)間中的每一條數(shù)據(jù)。

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

Next-Key Locks

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

RC級別存在幻讀分析

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

假設(shè)account表有4條數(shù)據(jù)。

開啟事務(wù)A，執(zhí)行當(dāng)前讀，查詢id>2的所有記錄。

再開啟事務(wù)B，插入id=5的一條數(shù)據(jù)。

事務(wù)B插入數(shù)據(jù)成功后，再修改id=3的記錄

回到事務(wù)A,再次執(zhí)行id>2的當(dāng)前讀查詢

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

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

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

RR 級別解決幻讀分析

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

假設(shè)account表有4條數(shù)據(jù)，RR級別。

開啟事務(wù)A，執(zhí)行當(dāng)前讀，查詢id>2的所有記錄。

再開啟事務(wù)B，插入id=5的一條數(shù)據(jù)。

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

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

原文標(biāo)題：一文徹底讀懂 MySQL 事務(wù)的四大隔離級別

文章出處：【微信公眾號：數(shù)據(jù)分析與開發(fā)】歡迎添加關(guān)注！文章轉(zhuǎn)載請注明出處。

責(zé)任編輯：haq