數據庫事務系列－MySQL跨行事務模型

說來和MySQL卻是有緣，畢業的第一份工做就被分配到了RDS團隊，主要負責把MySQL弄到雲上作成數據庫服務。雖然說成天和MySQL打交道，但說實話那段時間並無很深刻的理解MySQL內核，作的事情基本都是圍繞着MySQL作管控系統，比較上層。好在周邊都是MySQL內核神級人物，在他們的薰陶下多多少少對MySQL的一些基本知識有一些零碎的記錄和模糊的認識，這些基礎對於今天整理理解MySQL跨行事務模型很是重要。更重要的，有不少不解的地方也能夠向大神請教。

MySQL事務模型在網上也有不少的介紹，在寫這篇文章以前本人也翻看了不少資料做爲參考，以期讓本身理解的更加深刻全面。看了大多數介紹文章以後發現部分文章並不完整，好比有的只介紹了幾種隔離級別下MySQL的表現，並無從技術角度進行解讀。有的文章說的倒很全面，但缺少些許條理，讀起來並不容易理解。這也是筆者但願可以帶給你們一點不同的東西，從技術角度進行解讀，而且利於理解。

MySQL事務原子性保證

事務原子性要求事務中的一系列操做要麼所有完成，要麼不作任何操做，不能只作一半。原子性對於原子操做很容易實現，就像HBase中行級事務的原子性實現就比較簡單。但對於多條語句組成的事務來講，若是事務執行過程當中發生異常，須要保證原子性就只能回滾，回滾到事務開始前的狀態，就像這個事務根本沒有發生過同樣。如何實現呢？

MySQL實現回滾操做徹底依賴於undo log，多說一句，undo log在MySQL除了用來實現原子性保證以外，還用來實現MVCC，下文也會涉及到。使用undo實現原子性在操做任何數據以前，首先會將修改前的數據記錄到undo log中，再進行實際修改。若是出現異常須要回滾，系統能夠利用undo中的備份將數據恢復到事務開始以前的狀態。下圖是MySQL中表示事務的基本數據結構，其中與undo相關的字段爲insert_undo和update_undo，分別指向本次事務所產生的undo log。

事務回滾根據update_undo（或者insert_undo）找到對應的undo log，作逆向操做便可。對於已經標記刪除的數據清理刪除標記，對於更新數據直接回滾更新；插入操做稍微複雜一些，不只須要刪除數據，還須要刪除相關的彙集索引以及二級索引記錄。

undo log是MySQL內核中很是重要的一塊內容，涉及知識比較多並且複雜，好比：

• 1. undo log必須在數據修改以前持久化，undo log持久化需不須要記錄redo以防止宕機異常？若是須要就又涉及宕機恢復…

• 2. 經過undo log如何實現MVCC？

• 3. 那些undo log能夠在什麼場景下回收清理？如何清理？

MySQL事務一致性保證：強一致性事務保證

MySQL事務隔離級別

---

Read Uncommitted（RU技術解讀：使用X鎖實現寫寫併發）

Read Uncommitted只實現了寫寫併發控制，並無有效的讀寫併發控制，致使當前事務可能讀到其餘事務中還未提交的修改數據，這些數據準確性並不靠譜（有可能被回滾掉），所以在此基礎上做出的一切假設就都不靠譜的。在現實場景中不多有業務會選擇該隔離級別。

寫寫併發實現機制和HBase並沒有兩樣，都是使用兩階段鎖協議對相應記錄加行鎖實現。不過MySQL中行鎖機制比較複雜，根據行記錄是不是主鍵索引、惟一索引、非惟一索引或者無索引等分爲多種加鎖狀況。

• 1. 若是id列是主鍵索引，MySQL只會爲聚簇索引記錄加鎖。

• 2. 若是id列是惟一二級索引，MySQL會爲二級索引葉子節點以及聚簇索引記錄加鎖。

• 3. 若是id列是非惟一索引，MySQL會爲全部知足條件(id = 15)的二級索引葉子節點以及對應的聚簇索引記錄加鎖。

• 4. 若是id列是無索引的，SQL會走聚簇索引全表掃描，並將掃描結果加載到SQL Server層進行過濾，所以InnoDB會爲掃描過的全部記錄先加上鎖，若是SQL Server層過濾不符合條件，InnoDB會釋放該鎖。所以InnoDB會爲掃描到的全部記錄都加鎖，很恐怖吧!

接下來不管是RC、RR，抑或是Serialization，寫寫併發控制都使用上述機制，因此再也不贅述。接下來會重點分析RC和RR隔離級別中的讀寫併發控制機制。

在詳細介紹RC和RR以前，有必要在此先行介紹MySQL中MVCC機制，由於RC和RR都使用MVCC機制實現事務之間的讀寫併發。只不過二者在實現細節上有一些區別，具體區別接下來再聊。

MVCC in MySQL

MySQL中MVCC機制相比HBase來講要複雜的多，涉及的數據結構也比較複雜。爲了解釋的比較清晰，以一個栗子爲模版進行解釋。好比當前有一行記錄以下圖所示：

前面四列是該行記錄的實際列值，須要重點關注的是DB_TRX_ID和DB_ROLL_PTR兩個隱藏列（對用戶不可見）。其中DB_TRX_ID表示修改該行事務的事務ID，而DB_ROLL_PTR表示指向該行回滾段的指針，該行記錄上全部版本數據，在undo中都經過鏈表形式組織，該值實際指向undo中該行的歷史記錄鏈表。

如今假設有一個事務trx2修改了該行數據，該行記錄就會變爲下圖形式，DB_TRX_ID爲最近修改該行事務的事務ID(trx2)，DB_ROLL_PTR指向undo歷史紀錄鏈表：

瞭解了MySQL行記錄以後，再來看看事務的基本結構，下圖是MySQL的事務數據結構，上文咱們提到過。事務在開啓以後會建立一個數據結構存儲事務相關信息、鎖信息、undo log以及很是重要的read_view信息。

read_view保存了當前事務開啓時整個MySQL中全部活躍事務列表，以下圖所示，在當前事務開啓的時候，系統中活躍的事務有trx四、trx六、trx7以及trx10。另外，up_trx_id表示當前事務啓動時，當前事務鏈表中最小的事務ID；low_trx_id表示當前事務啓動時，當前事務鏈表中最大的事務ID。

read_view是實現MVCC的一個關鍵點，它用來判斷記錄的哪一個版本對當前事務可見。若是當前事務要讀取某行記錄，該行記錄的版本號（事務ID）爲trxid，那麼：

• 1. 若是trxid < up_trx_id，說明該行記錄所在的事務已經在當前事務建立以前就提交了，因此該行記錄對當前事務可見。

• 2. 若是trxid > low_trx_id，說明該行事務所在的事務是在當前事務建立以後纔開啓，因此該行記錄對當前事務不可見。

• 3. 若是up_trx_id < trxid < low_trx_id， 那麼代表該行記錄所在事務在本次新事務建立的時候處於活動狀態。從up_trx_id到low_trx_id進行遍歷，若是trxid等於他們之中的某個事務id的話，那麼不可見，不然可見。

如下面行記錄爲例，該行記錄存在多個版本（trx二、trx五、trx7以及trx12），其中trx12是最新版本。看看該行記錄中哪一個版本對當前事務可見。

• 1. 該行記錄的最新版本爲trx12，與當前事務read_view進行對比發現，trx12大於當前活躍事務列表中的最大事務trx10，表示trx12是在當前事務建立以後纔開啓的，所以不可見。

• 2. 再查看該行記錄的第二個最新版本爲trx7，與當前事務read_view對比發現，trx7介於當前活躍事務列表最小事務ID和最大事務ID之間，代表該行記錄所在事務在當前事務建立的時候處於活動狀態，在活躍列表中遍歷發現trx7確實存在，說明該事務尚未提交，因此對當前事務不可見。

• 3. 繼續查看該記錄的第三個最新版本trx5，也介於當前活躍事務列表最小事務ID和最大事務ID之間，代表該行記錄所在事務在當前事務建立的時候處於活動狀態，但遍歷發現該版本並不在活躍事務列表中，說明trx5對應事務已經提交（注：事務提交時間與事務編號沒有任何關聯，有可能事務編號大的事務先提交，事務編號小的事務後提交），所以trx5版本行記錄對當前事務可見，直接返回。

---

Read Committed（技術解讀：寫寫併發使用X鎖，讀寫併發使用MVCC避免髒讀）

上文介紹了MySQL中MVCC技術實現機制，但要明白RC隔離級別下事務可見性，還須要get一個核心點：RC隔離級別下的事務在每次執行select時都會生成一個最新的read_view代替原有的read_view。

如上圖所示，左側爲1號事務，在不一樣時間點對id=1的記錄分別查詢了三次。右側爲2號事務，對id=1的記錄進行了更新。更新前該記錄只有一個版本，更新好變成了兩個版本。

1號事務在RC隔離級別下每次執行select請求都會生成一個最新的read_view，前兩次查詢生成的全局事務活躍列表中包含trx2，所以根據MVCC規定查到的記錄爲老版本；最後一次查詢的時間點位於2號事務提交以後，所以生成的全局活躍事務列表中不包含trx2，此時在根據MVCC規定查到的記錄就是最新版本記錄。

Repeatable Read（技術解讀：寫寫併發使用X鎖，讀寫併發使用MVCC避免不可重複讀；當前讀使用Gap鎖避免幻讀）

和RC模式不一樣，RR模式下事務不會再每次執行select的時候生成最新的read_view，而是在事務第一次select時就生成read_view，後續不會再變動，直至當前事務結束。這樣能夠有效避免不可重複讀，使得當前事務在整個事務過程當中讀到的數據都保持一致。示意圖以下所示：

這個就很容易理解，三次查詢所使用的全局活躍事務列表都同樣，且都是第一次生成的read_view，那以後查到的記錄必然和第一次查到的記錄一致。

RR隔離級別可以避免幻讀嗎？

若是對幻讀還不瞭解的話，能夠參考該系列的第一篇文章。以下圖所示，1號事務對針對id>1的過濾條件執行了三次查詢，2號事務執行了一次插入，插入的記錄恰好符合id>1這個條件。能夠看出來，三次查詢獲得的數據是一致的，這個是由RR隔離級別的MVCC機制保證的。這麼看來，是避免了幻讀，可是在最後1號事務在id=2處插入一條記錄，MySQL會返回Duplicate entry的錯誤，可見避免了幻讀是一種假象。

嚴格意義避免幻讀（技術解讀：當前讀使用Gap鎖避免幻讀）

以前提到的全部RR級別的select語句咱們稱爲快照讀，快照讀可以保證不可重複讀，但並不能避免幻讀。因而MySQL又提出」當前讀」的概念，常見的當前讀語句有：

1.  select for update

2.  select lock in share mode

3.  update / delete

而且規定，RR級別下當前讀語句會給記錄加上一種特殊的鎖－Gap鎖，Gap鎖並不鎖定某個具體的記錄，而是鎖定記錄與記錄之間的間隔，保證這個間隔中不會插入新的其餘記錄。下圖是一個示意圖：

上圖中1號事務首先執行了一個當前讀的select語句，這個語句會在 id > 0的全部間隔加上Gap鎖，接下來2號事務在id = 3處執行插入時系統就會返回Lock wait timeout execcded的異常。固然，其餘事務能夠在id <= 0的條件下插入成功，這沒問題。

Serializable （技術解讀：S鎖(讀)＋X鎖(寫)）

Serialization隔離級別是最嚴格的隔離級別，全部讀請求都會加上讀鎖，不分快照讀和當前讀，全部寫會加上寫鎖。固然，這種隔離級別的性能由於鎖開銷而相對最差。

MySQL事務持久性保證

MySQL事務持久化策略和HBase基本相同，可是涉及的組件相對比較多，主要有doublewrite、redo log以及binlog：

1. MySQL數據持久化（DoubleWrite）

實際上MySQL的真實數據寫入分爲兩次寫入，一次寫入到一個稱爲DoubleWrite的地方，寫成功以後再真實寫入數據所在磁盤。爲何要寫兩次？這是由於MySQL數據頁大小與磁盤一次原子操做大小不一致，有可能會出現部分寫入的狀況，好比默認InnoDB數據頁大小爲16K，而磁盤一次原子寫入大小爲512字節（扇區大小），這樣一個數據頁寫入須要屢次IO，這樣一旦中間發生異常就會出現數據丟失。另外須要注意的是DoubleWrite性能並不會影響太大，由於寫入DoubleWrite是順序寫入，對性能影響來講不是很大。

2. redolog持久化策略（innodb_flush_log_at_trx_commit）

redolog是InnoDB的WAL，數據先寫入redolog並落盤，再寫入更新到bufferpool。redolog的持久化策略和HBase中hlog的持久化策略一致，默認爲1，表示每次事務提交以後log就會持久化到磁盤；該值爲0表示每隔1秒鐘左右由異步線程持久化到磁盤，這種狀況下MySQL發生宕機有可能會丟失部分數據。該值爲2表示每次事務提交以後log會flush到操做系統緩衝區，再由操做系統異步flush到磁盤，這種狀況下MySQL發生宕機不會丟失數據，但機器宕機有可能會丟失部分數據。

3. binlog持久化策略（sync_binlog）

binlog做爲Server層的日誌系統，主要以events的形式順序紀錄了數據庫的各類操做，同時能夠紀錄每次操做所花費的時間。在MySQL官方文檔上，主要介紹了Binlog的兩個最基本核心做用：備份和複製，所以binlog的持久化會必定程度影響數據備份和複製的完整性。和redo持久化策略相同，可取值有0，1，N。默認爲0，表示寫入操做系統緩衝區，異步flush到磁盤。該值爲1表示同步寫入磁盤。爲N則表示每寫N次操做系統緩衝就執行一次刷新操做。

總結一下，本文是數據庫事務系列文章的第三篇，核心介紹了MySQL的單機跨行事務模型，其中對隔離性所涉及到的鎖技術、MVCC機制進行了比較詳細的說明。對事務原子性、持久性等相關特性也進行簡單的分析和說明。接着筆者將會帶你們一塊兒聊聊分佈式事務模型，看看和單機事務模型到底有何區別。