上圖是數(shù)據(jù)庫版本可見性規(guī)則，對于當前事務(wù)的啟動瞬間來說，一個數(shù)據(jù)版本的row trx_id，有以下幾種可能：

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

2. 如果落在灰色部分，表示這個版本是由將來啟動的事務(wù)生成的，是肯定不可見的；

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

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

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

比如，對于圖2中的數(shù)據(jù)來說，如果有一個事務(wù)，它的低水位是21，那么當它訪問這一行數(shù)據(jù)時，就會從V4通過U3計算出V3，所以在它看來，這一行的值是11。

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

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

接下來我們用一個例子來鞏固一下MVCC的知識，例子如下：

下面是一個只有兩行的表的初始化語句。

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命令并不是一個事務(wù)的起點，在執(zhí)行到它們之后的第一個操作InnoDB表的語句，事務(wù)才真正啟動。如果你想要馬上啟動一個事務(wù)，可以使用start transaction with consistent snapshot這個命令。

還需要注意的是，我們的例子中如果沒有特別說明，都是默認autocommit=1。

在這個例子中，事務(wù)C沒有顯式地使用begin/commit，表示這個update語句本身就是一個事務(wù)，語句完成的時候會自動提交。事務(wù)B在更新了行之后查詢; 事務(wù)A在一個只讀事務(wù)中查詢，并且時間順序上是在事務(wù)B的查詢之后。

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

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

接下來我們用假設(shè)分析法，進行如下的假設(shè)：

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

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

3. 三個事務(wù)開始前，(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]。

為了便于我們分析，接下來我們通過一個圖去分析，如下圖所示：

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

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

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

你可能注意到了，在事務(wù)A查詢的時候，其實事務(wù)B還沒有提交，但是它生成的(1,3)這個版本已經(jīng)變成當前版本了。但這個版本對事務(wù)A必須是不可見的，否則就變成臟讀了。

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

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

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

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

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

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

一個數(shù)據(jù)版本，對于一個事務(wù)視圖來說，除了自己的更新總是可見以外，有三種情況：

1. 版本未提交，不可見；

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

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

現(xiàn)在，我們用這個規(guī)則來判斷圖4中的查詢結(jié)果，事務(wù)A的查詢語句的視圖數(shù)組是在事務(wù)A啟動的時候生成的，這時候：

• (1,3)還沒提交，屬于情況1，不可見；

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

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

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

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

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

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

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

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

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

這里我們提到了一個概念，叫作當前讀。其實，除了update語句外，select語句如果加鎖，也是當前讀。

因此，如果把事務(wù)A的查詢語句select * from t where id=1修改一下，加上lock in share mode或 for update，也都可以讀到版本號是101的數(shù)據(jù)，返回的k的值是3。下面這兩個select語句，就是分別加了讀鎖（S鎖，共享鎖）和寫鎖（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’，會怎么樣呢？如下圖所示：

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

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

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

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

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

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

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

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

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

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

六、總結(jié)

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