本文意在弄清楚這些概念間的關(guān)系及其作用。弄清Mysql在開(kāi)啟事務(wù)的情況下，每條sql執(zhí)行時(shí)的加鎖操作和MVCC版本控制。為使討論簡(jiǎn)單，本文忽略了GAP鎖（間隙鎖、范圍鎖）。

我們經(jīng)常所高并發(fā)，高可用。就是從質(zhì)和量來(lái)評(píng)估，任何事物都可以從這兩個(gè)角度來(lái)分析。在Mysql數(shù)據(jù)庫(kù)中，事務(wù)就是用來(lái)保證質(zhì)的，MVCC就是用來(lái)保證量的。

事務(wù)

我們使用事務(wù)來(lái)保證每一條SQL語(yǔ)句的結(jié)果執(zhí)行符合我們的預(yù)期。我們說(shuō)事務(wù)必須具備ACID特性。ACID中的三者：原子性、一致性和持久性其實(shí)描述的都差不多，保證SQL執(zhí)行結(jié)果的可靠性。而隔離性就比較復(fù)雜了，隔離性描述的是在并發(fā)場(chǎng)景下數(shù)據(jù)庫(kù)的表現(xiàn)，但并發(fā)量并不是固定的，而不同的業(yè)務(wù)可能有不同的需求，為了使數(shù)據(jù)庫(kù)能適應(yīng)不同的并發(fā)場(chǎng)景，所以偉大的人們又定義了四種隔離級(jí)別：Read Uncommited，Read Committed (RC)，Repeatable Read (RR)，Serializable。隨著數(shù)據(jù)庫(kù)隔離級(jí)別的提高，數(shù)據(jù)的并發(fā)能力也有所下降。

隔離級(jí)別

標(biāo)準(zhǔn)隔離級(jí)別下數(shù)據(jù)庫(kù)會(huì)怎么表現(xiàn)，我們這里只討論共享鎖和排它鎖這兩概念，讀加共享鎖，寫(xiě)加排它鎖：

在RC隔離級(jí)別下，修改數(shù)據(jù)會(huì)加排它鎖，事務(wù)結(jié)束釋放，其他事務(wù)不許讀，解決臟讀問(wèn)題。（共享鎖當(dāng)場(chǎng)釋放）
在RR隔離級(jí)別下，讀數(shù)據(jù)加共享鎖，事務(wù)結(jié)束釋放，其他事務(wù)不許修改，解決不可重復(fù)讀。（共享鎖事務(wù)結(jié)束釋放）

實(shí)際上都把操作串行化了。而Mysql對(duì)其進(jìn)行了優(yōu)化，一個(gè)事務(wù)讀時(shí)其他事務(wù)不能寫(xiě)，一個(gè)事務(wù)寫(xiě)時(shí)其他事務(wù)不能讀？我不這么干照樣能解決臟讀和不可重復(fù)讀問(wèn)題。MVCC出現(xiàn)了。（這也使得問(wèn)題變得越來(lái)越復(fù)雜，而不一樣的地方也開(kāi)始出現(xiàn)在RR隔離級(jí)別下，碰巧Mysql的默認(rèn)隔離級(jí)別就是RR）

MVCC

MVCC即多版本并發(fā)控制，使用了雙版本號(hào)來(lái)解決數(shù)據(jù)的隔離問(wèn)題。（“create”一個(gè)版本號(hào)，“delete”一個(gè)版本號(hào)，修改操作拆分為“delete”和“create”）每個(gè)事務(wù)在開(kāi)始對(duì)每張表增刪改查操作時(shí)都會(huì)生成一個(gè)版本號(hào)，每個(gè)事務(wù)只能查到“create”小于本版本號(hào)和“delete”大于本版本號(hào)的數(shù)據(jù)。這樣，增刪查操作就完全可以并發(fā)進(jìn)行了，只有修改操作是一定要排隊(duì)的。這樣，就算沒(méi)有共享鎖也解決了不可重復(fù)讀問(wèn)題，因?yàn)槠渌聞?wù)修改后，數(shù)據(jù)的版本號(hào)比我大，我不會(huì)讀到。

MVCC在RR隔離級(jí)別下的并發(fā)

引入MVCC之后，看似很美好。然而大家有沒(méi)有想過(guò)兩個(gè)事務(wù)先后對(duì)一條數(shù)據(jù)做更新操作，然后兩個(gè)事務(wù)再讀取那條數(shù)據(jù)，分別讀到什么？哈哈，這根本是不可能出現(xiàn)的，因?yàn)樾薷牟僮魇谴械?，另一個(gè)事務(wù)必須先commit本事務(wù)才能修改。好，換個(gè)問(wèn)題，兩個(gè)事務(wù)先后對(duì)一條數(shù)據(jù)做+1操作，另一個(gè)事務(wù)提交后，本事務(wù)再+1，再讀取那條數(shù)據(jù)，本事務(wù)是讀取到+1還是+2的結(jié)果？如果讀取到+2，那不是破壞了隔離性，讀到了其他事務(wù)提交的數(shù)據(jù)么？

然而事實(shí)確實(shí)是這樣，其他事務(wù)已經(jīng)提交，本事務(wù)也已修改過(guò)那條數(shù)據(jù)了，之后當(dāng)然要讀到+2才行。雖然本來(lái)是0，本事務(wù)明明只加了1，可讀取后卻變成2了，有點(diǎn)不適應(yīng)。確實(shí)，在標(biāo)準(zhǔn)的RR隔離級(jí)別下，因?yàn)椴僮鞫际谴械?，本事?wù)讀取一行數(shù)據(jù)后，其他事務(wù)就不能修改這條數(shù)據(jù)了，這條數(shù)據(jù)永遠(yuǎn)只有本事務(wù)在操作，所以嚴(yán)格滿(mǎn)足隔離性。但是Mysql的RR增強(qiáng)了讀與寫(xiě)的并發(fā)，只有當(dāng)兩個(gè)事務(wù)同時(shí)修改一條數(shù)據(jù)需要串行，其他所有操作都可以并行。所以造成了這種結(jié)果，好像出現(xiàn)了不可重復(fù)讀。但是這種不可重復(fù)讀實(shí)際上是符合我們的直觀感受的，在本事務(wù)對(duì)數(shù)據(jù)修改后，當(dāng)然要讀取到最新的數(shù)據(jù)。

要對(duì)其過(guò)程進(jìn)行分析的話(huà)：

數(shù)據(jù)create版本號(hào)為0

事務(wù)1版本號(hào)為1，讀取數(shù)據(jù)value=0

事務(wù)2版本號(hào)為2，修改數(shù)據(jù)value+1=1，原數(shù)據(jù)delete版本號(hào)為2，新數(shù)據(jù)create版本號(hào)更新為2，commit

事務(wù)1修改數(shù)據(jù)value+1=2，（由于修改是當(dāng)前讀，永遠(yuǎn)讀取版本號(hào)最大的數(shù)據(jù)，所以讀取到value為1）修改后delete版本號(hào)為1，

新數(shù)據(jù)create版本號(hào)為1

本事務(wù)讀取數(shù)據(jù)value=2

深入分析：

其實(shí)上面的描述也是有漏洞的，如果有第三個(gè)事務(wù)版本號(hào)為3呢？因?yàn)榘姹咎?hào)為3，是不是可以直接讀取事務(wù)1、2未提交的數(shù)據(jù)？實(shí)際上在MVCC中，每個(gè)事務(wù)還有一個(gè)最低可見(jiàn)版本low_limit_id（事務(wù)號(hào) >= low_limit_id的記錄，對(duì)于當(dāng)前事務(wù)都是不可見(jiàn)的），把當(dāng)前正在執(zhí)行還沒(méi)commit的事務(wù)給過(guò)濾掉了。例如事務(wù)3，雖然版本號(hào)為3，但是low_limit_id=1，所以事務(wù)1和事務(wù)2的修改對(duì)3都是不可見(jiàn)的。

總結(jié)

為了解決隔離性問(wèn)題，都沒(méi)有使用完全copy數(shù)據(jù)這種笨方法。傳統(tǒng)數(shù)據(jù)庫(kù)使用共享鎖和排它鎖使讀寫(xiě)操作串行；Mysql使用MVCC和排它鎖，讀寫(xiě)可并行。Mysql在RR隔離級(jí)別以下，和傳統(tǒng)方式表現(xiàn)一致，在RR隔離級(jí)別，和傳統(tǒng)方式有差異，體現(xiàn)在本事務(wù)更新某條數(shù)據(jù)后，能讀取到其他事務(wù)對(duì)該條數(shù)據(jù)已提交的修改。