一、前言

眾所周知，MySQL的在RR隔離級別下查詢數(shù)據(jù)，是可以保證數(shù)據(jù)不受其它事物影響，而在RC隔離級別下只要其它事物commit后，數(shù)據(jù)都會(huì)讀到commit之后的數(shù)據(jù)，那么事物隔離的原理是什么？是通過什么實(shí)現(xiàn)的呢？那肯定是通過MVCC機(jī)制（Multi-Version Concurrency Control，即多版本并發(fā)控制）。

注：MySQL的InnoDB引擎之所以能夠支持高性能的并發(fā)性能，就是由于MySQL的MVCC機(jī)制（歸功于undo log、Read-View、），但是本篇不對MVCC過多的介紹。

參考資料：《MySQL實(shí)戰(zhàn)45講》系列，雖然講解的比較清晰，但是仍然需要理解，比如關(guān)于視圖數(shù)組部分我認(rèn)為是相比較而言沒有解釋清楚，所以結(jié)合資料與自己見解加以記錄！

二、RC與RR隔離級別

我們分別開啟RC與RR隔離級別實(shí)驗(yàn)說明，首先假設(shè)有account賬戶表，在事務(wù)ABC開啟前，賬戶中的余額balance為1，即

select balance from account =1; # 結(jié)果為1

2.1、RR事務(wù)隔離級別下查詢結(jié)果

當(dāng)在RR事務(wù)隔離級別分別開啟三個(gè)事務(wù)，在不同時(shí)間段內(nèi)做如下操作

• 事務(wù)A（顯式開啟事務(wù)，手動(dòng)commit提交）：查詢余額
• 事務(wù)B（顯式開啟事務(wù)，手動(dòng)commit提交）：對id=1的余額加1
• 事務(wù)C（不顯式開啟事務(wù)，自動(dòng)提交）：對id=1的余額加1

我們從時(shí)間邏輯上分為三個(gè)階段，分析結(jié)果

• 第一階段：事務(wù)A立馬開始事務(wù)，隨后事務(wù)B也緊跟著立馬開始事務(wù)，然后事務(wù)C首先更新balance為2成功，當(dāng)前balance=2；
• 第二階段：事務(wù)B更新balance的值，此時(shí)先讀到當(dāng)前balance最新值為2，隨后set balance=balance+1成功，當(dāng)前balance=3；
• 第三階段：事務(wù)A查詢balance的值，此時(shí)的值為1（這里為什么等于1呢，是怎么實(shí)現(xiàn)的呢？不應(yīng)該是當(dāng)前最新值3嗎？這就是本篇博文討論的重點(diǎn)），最后commit結(jié)束事務(wù)，緊接著事務(wù)B也commit結(jié)束事務(wù)

最后事務(wù)A讀取balance的結(jié)果是1，理所當(dāng)然，RR即為可重復(fù)讀，即一個(gè)事務(wù)在執(zhí)行過程中看到的數(shù)據(jù)，總是跟這個(gè)事務(wù)啟動(dòng)時(shí)看到的數(shù)據(jù)是一致的，當(dāng)前事務(wù)不管有沒有提交，都不會(huì)影響數(shù)據(jù)，我只需要讀取基于快照的數(shù)據(jù)即可，這就是快照讀。但是我們要討論的是如何在MVCC機(jī)制下實(shí)現(xiàn)？

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

2.2、RC事務(wù)隔離級別下查詢結(jié)果

同樣地，我們在RC隔離下，開啟事務(wù)ABC，觀察事務(wù)A最后的balance結(jié)果。

最后事務(wù)A讀取balance的結(jié)果是2，理所當(dāng)然，RC即為讀可提交，字面意思就是其他事務(wù)只要提交后，當(dāng)前事務(wù)我就能立馬讀取到最新當(dāng)前值，這就是當(dāng)前讀。但是我們要討論的是如何在MVCC機(jī)制下實(shí)現(xiàn)？

實(shí)際上這是因?yàn)閷?shí)現(xiàn)MVCC時(shí)用到的一致性讀視圖，即consistent read view，用于支持RC（Read Committed，讀提交）和RR（Repeatable Read，可重復(fù)讀）隔離級別的實(shí)現(xiàn)。

三、事務(wù)隔離在MVCC的實(shí)現(xiàn)

在探討MVCC如何實(shí)現(xiàn)事務(wù)隔離前，我們需要知道是視圖數(shù)組、一致性視圖等概念，才能幫助更好理解MVCC幫助事務(wù)實(shí)現(xiàn)了隔離。

3.1、數(shù)據(jù)行ROW的多版本

InnoDB里面每個(gè)事務(wù)有一個(gè)唯一的事務(wù)ID，叫作transaction id。它是在事務(wù)開始的時(shí)候向InnoDB的事務(wù)系統(tǒng)申請的，是按申請順序嚴(yán)格遞增的。

而每行數(shù)據(jù)也都是有多個(gè)版本的。每次事務(wù)更新數(shù)據(jù)的時(shí)候，都會(huì)生成一個(gè)新的數(shù)據(jù)版本，并且把transaction id賦值給這個(gè)數(shù)據(jù)版本的事務(wù)ID，記為row trx_id。同時(shí)，舊的數(shù)據(jù)版本要保留，并且在新的數(shù)據(jù)版本中，能夠有信息可以直接拿到它（通過undo_log文件找到）。

也就是說，數(shù)據(jù)表中的一行記錄，其實(shí)可能有多個(gè)版本(row)，每個(gè)版本有自己的row trx_id。

對某一個(gè)數(shù)據(jù)行ROW某個(gè)時(shí)刻經(jīng)過三次更新事務(wù)的多版本控制流程，畫如下圖加深理解。

從圖我們可以得到：

• ROW有四個(gè)版本V1-V4，即經(jīng)過三次更新balance后，當(dāng)前最新版本為V4，當(dāng)前balance已經(jīng)更新為4，是最新值
• InnoDB每次更新事務(wù)產(chǎn)生的transaction id都會(huì)賦值給row trx_id；
• 通過undo_log可以從V4撤回到V1,找到V1版本的balance=1，即undo_log回滾版本。

明白了數(shù)據(jù)行的ROW的多版本原理與實(shí)現(xiàn)后，可以幫助我們理解InnoDB是怎么定義并創(chuàng)建快照的！

3.2、視圖數(shù)組

下述部分出自資料中的原句，特別是紅色加深部分可能會(huì)比較難以理解，所以需要結(jié)合自己理解并畫圖

InnoDB是這么在事務(wù)開啟的時(shí)候定義快照的，哪些事務(wù)的操作我可以忽視，哪么我必須要保存在快照里?？梢岳斫鉃椋阂粋€(gè)事務(wù)只需要在啟動(dòng)的時(shí)候聲明說，“以我啟動(dòng)的時(shí)刻為準(zhǔn)，如果一個(gè)數(shù)據(jù)版本是在我啟動(dòng)之前生成的，就認(rèn)；如果是我啟動(dòng)以后才生成的，我就不認(rèn)，我必須要找到它的上一個(gè)版本”。

在實(shí)現(xiàn)上， InnoDB為每個(gè)事務(wù)構(gòu)造了一個(gè)數(shù)組，用來保存這個(gè)事務(wù)啟動(dòng)瞬間，當(dāng)前正在“活躍”的所有事務(wù)ID。“活躍”指的就是，啟動(dòng)了但還沒提交。數(shù)組里面事務(wù)ID的最小值記為低水位，當(dāng)前系統(tǒng)里面已經(jīng)創(chuàng)建過的事務(wù)ID的最大值加1記為高水位。這個(gè)視圖數(shù)組和高水位，就組成了當(dāng)前事務(wù)的一致性視圖（read-view）。

我對低水位與高水位的理解：

低水位=當(dāng)前所有啟動(dòng)了但未提交事務(wù)集合的ID最小值=當(dāng)前事務(wù)的上一個(gè)啟動(dòng)但未提交的事務(wù)ID最小值（所有活躍事務(wù)ID最小值）

高水位=當(dāng)前事務(wù)的ID（當(dāng)前ROW版本號/row trx_id）=已經(jīng)創(chuàng)建過事務(wù)ID的最大值+1

舉例說明：仍然以上述RR隔離級別下三個(gè)ABC事務(wù)為例

• 事務(wù)A開始前，系統(tǒng)里面只有一個(gè)活躍事務(wù)ID是99；
• 事務(wù)A、B、C的版本號分別是100、101、102，且當(dāng)前系統(tǒng)里只有這四個(gè)事務(wù)；
• 三個(gè)事務(wù)開始前，(id,balance)=(1,1）這一行數(shù)據(jù)的row trx_id是90。

這樣，事務(wù)A的視圖數(shù)組就是[99], 事務(wù)B的視圖數(shù)組是[99,100], 事務(wù)C的視圖數(shù)組是[99,100,101]。即視圖數(shù)組通用公式為：[{當(dāng)前事務(wù)開啟瞬間活躍事務(wù)ID集合}]。

而數(shù)據(jù)版本的可見性規(guī)則，就是基于rowtrx_id和一致性視圖對比結(jié)果得到的，所以我們還必須再了解下一致性視圖

3.3、一致性視圖

通過對視圖數(shù)組的理解，一致性視圖就更加容易了，即：這個(gè)視圖數(shù)組和高水位，就組成了當(dāng)前事務(wù)的一致性視圖（read-view）。

仍然以上述RR隔離級別下三個(gè)ABC事務(wù)為例

• 事務(wù)A開始前，系統(tǒng)里面只有一個(gè)活躍事務(wù)ID是99, 所以事物A開啟瞬間活躍事物集合為[99]；
• 事務(wù)A、B、C的版本號分別是100、101、102，且當(dāng)前系統(tǒng)里只有這四個(gè)事務(wù)，所以事物A、B、C高水位分別為100、101、102；
• 三個(gè)事務(wù)開始前，(id,balance)=(1,1）這一行數(shù)據(jù)的row trx_id是90。

這樣，事務(wù)A的一致性視圖就是[99,100], 事務(wù)B的一致性視圖是[99,100,101], 事務(wù)C的一致性視圖是[99,100,101,102]。即一致性視圖通用公式為：[{當(dāng)前事務(wù)開啟瞬間活躍事務(wù)ID集合}，當(dāng)前row trx_id]。

分析上述流程圖結(jié)果：

第一個(gè)有效更新版本是事物C，更新balance=2，這個(gè)時(shí)候的最新版本rowtrx_id=102，而之前的在事物ABC之前的活躍事物最新版本row trx_id為99，所以此時(shí)99已經(jīng)成為歷史版本1；

第二個(gè)有效更新版本是事物B，更新balance=3，這個(gè)時(shí)候最新版本rowtrx_id=101，而此時(shí)row trx_id=102成為歷史版本1，而rowtrx_id=99成為歷史版本2；

事物A查詢的時(shí)候，事物B是沒有提交，但生成的(id, balance)=(1, 3)已經(jīng)成為當(dāng)前最新版本，事物A讀取數(shù)據(jù)時(shí)，一致性視圖為[99, 100]，而讀數(shù)據(jù)都是從當(dāng)前版本切的然后對比row trx_id，所以會(huì)有以下流程：

• 找到(1,3)的時(shí)候，判斷出row trx_id=101，比高水位大，處于紅色區(qū)域，不可見；
• 接著，找到上一個(gè)歷史版本，一看row trx_id=102，比高水位大，處于紅色區(qū)域，不可見；
• 再往前找，終于找到了（1,1)，它的row trx_id=90，比低水位小，處于綠色區(qū)域，可見。

最后事物A無論在什么時(shí)候查詢，看到的數(shù)據(jù)都是一致性視圖[99, 100]生成的快照數(shù)據(jù)(1, 1)，即rowtrx_id=90時(shí)的數(shù)據(jù)。這就稱之為一致性讀。

總結(jié)：

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

• 版本未提交，不可見；
• 版本已提交，但是是在視圖創(chuàng)建后提交的，不可見；
• 版本已提交，而且是在視圖創(chuàng)建前提交的，可見。

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

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

3.4、當(dāng)前讀與快照讀

3.4.1、當(dāng)前讀與快照讀規(guī)則

當(dāng)然按照這個(gè)一致性讀的邏輯，事物B在事物C有效更新balance=2之后，但是事物B的視圖數(shù)組是在事物C生成的，所以理論上來說不應(yīng)該是事物B看到的是(id, balance)=(1, 1)這個(gè)數(shù)據(jù)（快照/歷史版本）嗎？而看不到當(dāng)前版本(1, 2)數(shù)據(jù)。為什么事物B在更新balance之后直接數(shù)據(jù)就成為(1, 3)了呢？

如果事物B在update之前select一次數(shù)據(jù)，看到的值確實(shí)是balance=1，但是update是不能在歷史版本上操作的，否則事物C的更新就會(huì)丟失，所以update操作都是在先讀取當(dāng)前版本，然后再更新。

也就說有這么一條規(guī)則：更新數(shù)據(jù)都是先讀后更新，而這個(gè)讀是讀當(dāng)前最新值，稱之為“當(dāng)前讀（currentread），而只查詢不讀的話就會(huì)讀取當(dāng)前快照，稱之為“快照讀”。所以在事物B更新balance之前，先查詢到最新的版本(1, 2)然后再更新為(1, 3)。而事物A查詢的快照數(shù)據(jù)為(1, 1)，而不是最新版本(1, 3)。

3.4.2、當(dāng)前讀與快照讀解釋

當(dāng)前讀：像select lock in share mode(共享鎖), select for update ; update, insert ,delete(排他鎖)這些操作都是一種當(dāng)前讀。就是它讀取的是記錄的最新版本，讀取時(shí)還要保證其他并發(fā)事務(wù)不能修改當(dāng)前記錄，會(huì)對讀取的記錄進(jìn)行加鎖。

快照讀：像不加鎖的select操作就是快照讀，即不加鎖的非阻塞讀；快照讀的前提是隔離級別不是串行級別，串行級別下的快照讀會(huì)退化成當(dāng)前讀。是基于多版本控制的，那么快照讀可能讀到的并不一定是數(shù)據(jù)的最新版本，而有可能是之前的歷史版本（快照數(shù)據(jù)）。

3.4.3、RC讀可提交下的視圖規(guī)則

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

在可重復(fù)讀隔離級別下，只需要在事務(wù)開始的時(shí)候創(chuàng)建一致性視圖，之后事務(wù)里的其他查詢，都共用這個(gè)一致性視圖；在讀提交隔離級別下，每一個(gè)語句執(zhí)行前都會(huì)重新算出一個(gè)新的視圖，此時(shí)start transaction with consistent snapshot就等同于普通的starttransaction/begin所以在RC隔離級別下，事物A與事物B查詢到的數(shù)據(jù)分別如下：

事物C立馬更新balance=2，然后自動(dòng)提交，生成最新版本(1, 2)，此時(shí)重新計(jì)算出視圖數(shù)據(jù)(1, 2);事物B查到此時(shí)的最新版本為(1, 2)，之后再更新為版本(1, 3)為當(dāng)前最新版本，查詢此時(shí)的事物B select到的balance=3（事物B更新balance=3之后立馬算出一個(gè)新的視圖，select就是根據(jù)此視圖得到的數(shù)據(jù)），而不是1。而此時(shí)事物B還未提交，對于事物A來說是看不見的，所以事物A此時(shí)讀取到的事物C提交的最新版本(1, 2)。

以上就是淺析MySQL如何實(shí)現(xiàn)事務(wù)隔離的詳細(xì)內(nèi)容，更多關(guān)于MySQL事務(wù)隔離的資料請關(guān)注腳本之家其它相關(guān)文章！