面試官靈魂的一擊：你懂MySQL事務(wù)嗎？

上圖是數(shù)據(jù)庫(kù)版本可見(jiàn)性規(guī)則，對(duì)于當(dāng)前事務(wù)的啟動(dòng)瞬間來(lái)說(shuō)，一個(gè)數(shù)據(jù)版本的row trx_id，有以下幾種可能：

1. 如果落在綠色部分，表示這個(gè)版本是已提交的事務(wù)或者是當(dāng)前事務(wù)自己生成的，這個(gè)數(shù)據(jù)是可見(jiàn)的；

2. 如果落在灰色部分，表示這個(gè)版本是由將來(lái)啟動(dòng)的事務(wù)生成的，是肯定不可見(jiàn)的；

3. 如果落在粉色部分，那就包括兩種情況

• (a) 若 row trx_id在數(shù)組中，表示這個(gè)版本是由還沒(méi)提交的事務(wù)生成的，不可見(jiàn)；

• (b) 若 row trx_id不在數(shù)組中，表示這個(gè)版本是已經(jīng)提交了的事務(wù)生成的，可見(jiàn)。

比如，對(duì)于圖2中的數(shù)據(jù)來(lái)說(shuō)，如果有一個(gè)事務(wù)，它的低水位是21，那么當(dāng)它訪問(wèn)這一行數(shù)據(jù)時(shí)，就會(huì)從V4通過(guò)U3計(jì)算出V3，所以在它看來(lái)，這一行的值是11。

你看，有了這個(gè)聲明后，系統(tǒng)里面隨后發(fā)生的更新，是不是就跟這個(gè)事務(wù)看到的內(nèi)容無(wú)關(guān)了呢？因?yàn)橹蟮母?，生成的版本一定屬于上面?或者3(a)的情況，而對(duì)它來(lái)說(shuō)，這些新的數(shù)據(jù)版本是不存在的，所以這個(gè)事務(wù)的快照，就是“靜態(tài)”的了。

所以你現(xiàn)在知道了，InnoDB利用了所有數(shù)據(jù)都有多個(gè)版本的這個(gè)特性，實(shí)現(xiàn)了“秒級(jí)創(chuàng)建快照”的能力。

接下來(lái)我們用一個(gè)例子來(lái)鞏固一下MVCC的知識(shí)，例子如下：

下面是一個(gè)只有兩行的表的初始化語(yǔ)句。

mysql>?CREATE?TABLE?`t`?(
??`id`?int(11)?NOT?NULL,
??`k`?int(11)?DEFAULT?NULL,
??PRIMARY?KEY?(`id`)
)?ENGINE=InnoDB;
insert?into?t(id,?k)?values(1,1),(2,2);

begin/start transaction命令并不是一個(gè)事務(wù)的起點(diǎn)，在執(zhí)行到它們之后的第一個(gè)操作InnoDB表的語(yǔ)句，事務(wù)才真正啟動(dòng)。如果你想要馬上啟動(dòng)一個(gè)事務(wù)，可以使用start transaction with consistent snapshot這個(gè)命令。

還需要注意的是，我們的例子中如果沒(méi)有特別說(shuō)明，都是默認(rèn)autocommit=1。

在這個(gè)例子中，事務(wù)C沒(méi)有顯式地使用begin/commit，表示這個(gè)update語(yǔ)句本身就是一個(gè)事務(wù)，語(yǔ)句完成的時(shí)候會(huì)自動(dòng)提交。事務(wù)B在更新了行之后查詢(xún); 事務(wù)A在一個(gè)只讀事務(wù)中查詢(xún)，并且時(shí)間順序上是在事務(wù)B的查詢(xún)之后。

讓我們想一下圖中的三個(gè)事務(wù)，分析一下事務(wù)A的語(yǔ)句返回的結(jié)果是什么？

答案：事務(wù)B查到的k的值是3，而事務(wù)A查到的k的值是1，是不是感到有點(diǎn)奇怪？

接下來(lái)我們用假設(shè)分析法，進(jìn)行如下的假設(shè)：

1. 事務(wù)A開(kāi)始前，系統(tǒng)里面只有一個(gè)活躍事務(wù)ID是99；

2. 事務(wù)A、B、C的版本號(hào)分別是100、101、102，且當(dāng)前系統(tǒng)里只有這四個(gè)事務(wù)；

3. 三個(gè)事務(wù)開(kāi)始前，(1,1）這一行數(shù)據(jù)的row trx_id是90。

這樣，事務(wù)A的視圖數(shù)組就是[99,100], 事務(wù)B的視圖數(shù)組是[99,100,101], 事務(wù)C的視圖數(shù)組是[99,100,101,102]。

為了便于我們分析，接下來(lái)我們通過(guò)一個(gè)圖去分析，如下圖所示：

這里需要說(shuō)明一下，start transaction with consistent snapshot;的意思是從這個(gè)語(yǔ)句開(kāi)始，創(chuàng)建一個(gè)持續(xù)整個(gè)事務(wù)的一致性快照。所以，在讀提交隔離級(jí)別下，這個(gè)用法就沒(méi)意義了，等效于普通的start transaction。

從圖中可以看到，第一個(gè)有效更新是事務(wù)C，把數(shù)據(jù)從(1,1)改成了(1,2)。這時(shí)候，這個(gè)數(shù)據(jù)的最新版本的row trx_id是102，而90這個(gè)版本已經(jīng)成為了歷史版本。

第二個(gè)有效更新是事務(wù)B，把數(shù)據(jù)從(1,2)改成了(1,3)。這時(shí)候，這個(gè)數(shù)據(jù)的最新版本（即row trx_id）是101，而102又成為了歷史版本。

你可能注意到了，在事務(wù)A查詢(xún)的時(shí)候，其實(shí)事務(wù)B還沒(méi)有提交，但是它生成的(1,3)這個(gè)版本已經(jīng)變成當(dāng)前版本了。但這個(gè)版本對(duì)事務(wù)A必須是不可見(jiàn)的，否則就變成臟讀了。

好，現(xiàn)在事務(wù)A要來(lái)讀數(shù)據(jù)了，它的視圖數(shù)組是[99,100]。當(dāng)然了，讀數(shù)據(jù)都是從當(dāng)前版本讀起的。所以，事務(wù)A查詢(xún)語(yǔ)句的讀數(shù)據(jù)流程是這樣的：

1. 找到(1,3)的時(shí)候，判斷出row trx_id=101，比高水位大，處于紅色區(qū)域，不可見(jiàn)；

2. 接著，找到上一個(gè)歷史版本，一看row trx_id=102，比高水位大，處于紅色區(qū)域，不可見(jiàn)；

3. 再往前找，終于找到了（1,1)，它的row trx_id=90，比低水位小，處于綠色區(qū)域，可見(jiàn)。

這樣執(zhí)行下來(lái)，雖然期間這一行數(shù)據(jù)被修改過(guò)，但是事務(wù)A不論在什么時(shí)候查詢(xún)，看到這行數(shù)據(jù)的結(jié)果都是一致的，所以我們稱(chēng)之為一致性讀。

這個(gè)判斷規(guī)則是我通過(guò)一些資料和高性能MYSQL中從代碼邏輯直接轉(zhuǎn)譯過(guò)來(lái)的，但是正如你所見(jiàn)，用于人肉分析可見(jiàn)性很麻煩。

一個(gè)數(shù)據(jù)版本，對(duì)于一個(gè)事務(wù)視圖來(lái)說(shuō)，除了自己的更新總是可見(jiàn)以外，有三種情況：

1. 版本未提交，不可見(jiàn)；

2. 版本已提交，但是是在視圖創(chuàng)建后提交的，不可見(jiàn)；

3. 版本已提交，而且是在視圖創(chuàng)建前提交的，可見(jiàn)。

現(xiàn)在，我們用這個(gè)規(guī)則來(lái)判斷圖4中的查詢(xún)結(jié)果，事務(wù)A的查詢(xún)語(yǔ)句的視圖數(shù)組是在事務(wù)A啟動(dòng)的時(shí)候生成的，這時(shí)候：

• (1,3)還沒(méi)提交，屬于情況1，不可見(jiàn)；

• (1,2)雖然提交了，但是是在視圖數(shù)組創(chuàng)建之后提交的，屬于情況2，不可見(jiàn)；

• (1,1)是在視圖數(shù)組創(chuàng)建之前提交的，可見(jiàn)。

你看，去掉數(shù)字對(duì)比后，只用時(shí)間先后順序來(lái)判斷，分析起來(lái)是不是輕松多了。所以，后面我們就都用這個(gè)規(guī)則來(lái)分析。

這時(shí)候你是不是有一個(gè)這樣的疑問(wèn)：事務(wù)B的update語(yǔ)句，如果按照一致性讀，好像結(jié)果不對(duì)哦？

事務(wù)B的視圖數(shù)組是先創(chuàng)建的，之后事務(wù)C才提交，不是應(yīng)該看不見(jiàn)(1,2)嗎，怎么能算出(1,3)來(lái)？

確實(shí)如此，如果事務(wù)B在更新之前查詢(xún)一次數(shù)據(jù)，這個(gè)查詢(xún)返回的k的值確實(shí)是1。

但是，當(dāng)它要去更新數(shù)據(jù)的時(shí)候，就不能再在歷史版本上更新了，否則事務(wù)C的更新就丟失了。

因此，事務(wù)B此時(shí)的set k=k+1是在（1,2）的基礎(chǔ)上進(jìn)行的操作，這里就用到了這樣一條規(guī)則：更新數(shù)據(jù)都是先讀后寫(xiě)的，而這個(gè)讀，只能讀當(dāng)前的值，稱(chēng)為**當(dāng)前讀。

因此，在更新的時(shí)候，當(dāng)前讀拿到的數(shù)據(jù)是(1,2)，更新后生成了新版本的數(shù)據(jù)(1,3)，這個(gè)新版本的row trx_id是101。所以，在執(zhí)行事務(wù)B查詢(xún)語(yǔ)句的時(shí)候，一看自己的版本號(hào)是101，最新數(shù)據(jù)的版本號(hào)也是101，是自己的更新，可以直接使用，所以查詢(xún)得到的k的值是3。

這里我們提到了一個(gè)概念，叫作當(dāng)前讀。其實(shí)，除了update語(yǔ)句外，select語(yǔ)句如果加鎖，也是當(dāng)前讀。

因此，如果把事務(wù)A的查詢(xún)語(yǔ)句select * from t where id=1修改一下，加上lock in share mode或 for update，也都可以讀到版本號(hào)是101的數(shù)據(jù)，返回的k的值是3。下面這兩個(gè)select語(yǔ)句，就是分別加了讀鎖（S鎖，共享鎖）和寫(xiě)鎖（X鎖，排他鎖）。

mysql>?select?k?from?t where id=1?lock in share?mode;
mysql>?select?k?from?t where id=1 for update;

假設(shè)事務(wù)C不是馬上提交的，而是變成了下面的事務(wù)C’，會(huì)怎么樣呢？如下圖所示：

事務(wù)C’的不同是，更新后并沒(méi)有馬上提交，在它提交前，事務(wù)B的更新語(yǔ)句先發(fā)起了。前面說(shuō)過(guò)了，雖然事務(wù)C’還沒(méi)提交，但是(1,2)這個(gè)版本也已經(jīng)生成了，并且是當(dāng)前的最新版本。那么，事務(wù)B的更新語(yǔ)句會(huì)怎么處理呢？

這時(shí)候，我們的兩階段鎖協(xié)議就要上場(chǎng)了。事務(wù)C’沒(méi)提交，也就是說(shuō)(1,2)這個(gè)版本上的寫(xiě)鎖還沒(méi)釋放。而事務(wù)B是當(dāng)前讀，必須要讀最新版本，而且必須加鎖，因此就被鎖住了，必須等到事務(wù)C’釋放這個(gè)鎖，才能繼續(xù)它的當(dāng)前讀。

那么回到之前的隔離界別中的事務(wù)的可重復(fù)讀的能力是怎么實(shí)現(xiàn)的？

可重復(fù)讀的核心就是一致性讀（consistent read）；而事務(wù)更新數(shù)據(jù)的時(shí)候，只能用當(dāng)前讀。如果當(dāng)前的記錄的行鎖被其他事務(wù)占用的話，就需要進(jìn)入鎖等待。

而讀提交的邏輯和可重復(fù)讀的邏輯類(lèi)似，它們最主要的區(qū)別是：

1. 在可重復(fù)讀隔離級(jí)別下，只需要在事務(wù)開(kāi)始的時(shí)候創(chuàng)建一致性視圖，之后事務(wù)里的其他查詢(xún)都共用這個(gè)一致性視圖；

2. 在讀提交隔離級(jí)別下，每一個(gè)語(yǔ)句執(zhí)行前都會(huì)重新算出一個(gè)新的視圖。

接下來(lái)再看一下，在讀提交隔離級(jí)別下，事務(wù)A和事務(wù)B的查詢(xún)語(yǔ)句查到的k，分別應(yīng)該是多少呢？如下圖所示：

可以看到此時(shí)事務(wù)A的查詢(xún)語(yǔ)句的視圖數(shù)組是在執(zhí)行這個(gè)語(yǔ)句的時(shí)候創(chuàng)建的，時(shí)間線上(1,2)、(1,3)的生成時(shí)間都在創(chuàng)建這個(gè)視圖數(shù)組的時(shí)刻之前。

但是，在這個(gè)時(shí)刻：(1,3)還沒(méi)提交，屬于情況1，不可見(jiàn)；(1,2)提交了，屬于情況3，可見(jiàn)。所以，這時(shí)候事務(wù)A查詢(xún)語(yǔ)句返回的是k=2。顯然地，事務(wù)B查詢(xún)結(jié)果k=3。

六、總結(jié)

本文從底層分析了MySQL的事務(wù)原理，希望對(duì)你們有所幫助，最后別忘了點(diǎn)贊喲?。。?