我身邊的高T，問了Java面試者這樣的問題......

你們好，我是來自JDL京東物流技術發展部邢煥傑， 今天來分享一個京東面試真題，這也是我前陣子聽我工位旁邊高T（高，實在是高）面試候選人的時候問的一個問題，他問，你能說說 MySQL的事務嗎？MVCC有了解嗎？話很少說，本文就深度解析一下MySQL事務及MVCC的實現原理。

事務定義及四大特性

• 事務是什麼？
• 事務的四大特性（簡稱ACID）：
• 原子性（Atomicity）：一個事務是一個不可分割的工做單位，事務中包括的操做要麼都作，要麼都不作。
• 一致性（Consistency）：事務必須是使數據庫從一個一致性狀態變到另外一個一致性狀態。一致性與原子性是密切相關的。
• 隔離性（Isolation）：一個事務的執行不能被其餘事務干擾。即一個事務內部的操做及使用的數據對併發的其餘事務是隔離的，併發執行的各個事務之間不能互相干擾.
• 持久性（Durability）：指一個事務一旦提交，它對數據庫中數據的改變就應該是永久性的,接下來的其餘操做或故障不該該對其有任何影響。

事務中常見問題

• 髒讀（dirty read）：就是一個A事務即使沒有提交，它對數據的修改也能夠被其餘事務B事務看到，B事務讀到了A事務還未提交的數據，這個數據有多是錯的，有可能A不想提交這個數據，這只是A事務修改數據過程當中的一箇中間數據，可是被B事務讀到了，這種行爲被稱做髒讀，這個數據被稱爲髒數據
• 不可重複讀（non-repeatable read）：在A事務內，屢次讀取同一個數據，可是讀取的過程當中，B事務對這個數據進行了修改，致使此數據變化了，那麼A事務再次讀取的時候，數據就和第一次讀取的時候不同了，這就叫作不可重複讀
• 幻讀（phantom read）：A事務屢次查詢數據庫，結果發現查詢的數據條數不同，A事務屢次查詢的間隔中，B事務又寫入了一些符合查詢條件的多條數據（這裏的寫入能夠是update，insert，delete），A事務再查的話，就像發生了幻覺同樣，怎麼忽然改變了這麼多，這種現象這就叫作幻讀

隔離級別——產生問題的緣由

多個事務互相影響，並無隔離好，就是咱們剛纔提到的事務的四大特性中的 隔離性（Isolation） 出現了問題 事務的隔離級別並無設置好，下面咱們來看下事務究竟有哪幾種隔離級別

• 隔離級別
• 讀未提交（read uncommitted RU）： 一個事務還沒提交時，它作的變動就能被別的事務看到
• 讀提交（read committed RC）： 一個事務提交以後，它作的變動纔會被其餘事務看到。
• 可重複讀（repeatable read RR）： 一個事務執行過程當中看到的數據，老是跟這個事務在啓動時看到的數據是一致的。固然在可重複讀隔離級別下，未提交變動對其餘事務也是不可見的。
• 串行化（serializable ）： 顧名思義是對於同一行記錄，「寫」會加「寫鎖」，「讀」會加「讀鎖」。當出現讀寫鎖衝突的時候，後訪問的事務必須等前一個事務執行完成，才能繼續執行。

咱們來看個例子，更加直觀的瞭解這四種隔離級別和上述問題髒讀，不可重複讀，幻讀的關係

下面咱們討論下當事務處於不一樣隔離級別狀況時，V1,V2,V3分別是什麼不一樣的值吧

• 讀未提交 (RU)： A事務能夠讀取到B事務修改的值，即使B事務沒有提交。因此V1就是200
• V1 : 200
• V2 : 200
• V3 : 200
• 讀提交（RC）： 當B事務沒有提交的時候，A事務不能夠看到B事務修改的值，只有提交之後才能夠看到
• V1 : 100
• V2 : 200
• V3 : 200
• 可重複讀（RR）： A事務屢次讀取數據，數據總和第一次讀取的同樣，
• V1 : 100
• V2 : 100
• V3 : 200
• 串行化（S）： 事務A在執行的時候，事務B會被鎖住，等事務A執行結束後，事務B才能夠繼續執行
• V1 : 100
• V2 : 100
• V3 : 200

MVCC原理

MVCC（Multi-Version Concurrency Control）多版本併發控制，是數據庫控制併發訪問的一種手段。

• 特別要注意MVCC只在 讀已提交(RC) 和 可重複度（RR） 這兩種事務隔離級別下才有效
• 是 數據庫引擎（InnoDB） 層面實現的，用來處理讀寫衝突的手段（不用加鎖），提升訪問性能

MVCC是怎麼實現的呢？它靠的就是版本鏈和一致性視圖

1. 版本鏈

• 版本鏈是一條鏈表，連接的是每條數據曾經的修改記錄

那麼這個版本鏈又是如何造成的呢，每條數據又是靠什麼連接起來的呢？

實際上是這樣的，對於InnoDB存儲引擎的表來講，它的聚簇索引記錄包含兩個隱藏字段

• trx_id: 存儲修改此數據的事務id，只有這個事務操做了某些表的數據後當更改操做發生的時候（update,delete,insert），纔會分配惟一的事務id,而且此事務id是遞增的
• roll_pointer: 指針，指向上一次修改的記錄
• row_id(非必須): 當有主鍵或者有不容許爲null的unique鍵時，不包含此字段

假如說當前數據庫有一條這樣的數據，假設是事務ID爲100的事務插入的這條數據，那麼此條數據的結構以下

後來，事務200，事務300，分別來修改此數據

因此此時的版本鏈以下

咱們每更改一次數據，就會插入一條undo日誌，而且記錄的roll_pointer指針會指向上一條記錄，如圖所示

1. 第一條數據是小杰，事務ID爲100
2. 事務ID爲200的事務將名稱從小杰改成了A
3. 事務ID爲200的事務將名稱從A又改成了B
4. 事務ID爲300的事務將名稱從B又改成了C

因此串成的鏈表就是 C -> B -> A -> 小杰 （從最新的數據到最老的數據）

2. 一致性視圖（ReadView）

須要判斷版本鏈中的哪一個版本是是當前事務可見的，所以有了一致性視圖的概念。其中有四個屬性比較重要

• m_ids: 在生成ReadView時，當前活躍的讀寫事務的事務id列表
• min_trx_id: m_ids的最小值
• max_trx_id: m_ids的最大值+1
• creator_trx_id: 生成該事務的事務id，單純開啓事務是沒有事務id的，默認爲0，creator_trx_id是0。

版本鏈中的當前版本是否能夠被當前事務可見的要根據這四個屬性按照如下幾種狀況來判斷

• 當 trx_id = creator_trx_id 時:當前事務能夠看見本身所修改的數據， 可見，
• 當 trx_id < min_trx_id 時   : 生成此數據的事務已經在生成readView前提交了， 可見
• 當  trx_id >= max_trx_id 時   :代表生成該數據的事務是在生成ReadView後纔開啓的， 不可見
• 當  min_trx_id <= trx_id < max_trx_id 時
• trx_id 在 m_ids 列表裏面 ：生成ReadView時，活躍事務還未提交，不可見
• trx_id 不在 m_ids 列表裏面 ：事務在生成readView前已經提交了，可見

若是某個版本數據對當前事務不可見，那麼則要順着版本鏈繼續向前尋找下個版本，繼續這樣判斷，以此類推。

注：RR和RC生成一致性視圖的時機不同 （這也是兩種隔離級別實現的主要區別）

• 讀提交（read committed RC） 是在每一次select的時候生成ReadView的
• 可重複讀（repeatable read RR）是在第一次select的時候生成ReadView的

下面我們一塊兒來舉個例子實戰一下。

RR與RC和MVCC的例子實戰

假如說，咱們有多個事務以下執行，咱們經過這個例子來分析當數據庫隔離級別爲RC和RR的狀況下，當時讀數據的一致性視圖和版本鏈，也就是MVCC，分別是怎麼樣的。

• 假設數據庫中有一條初始數據  姓名是java小杰要加油，id是1 （id,姓名,trx_id,roll_point），插入此數據的事務id是1
• 尤爲要指出的是，只有這個事務操做了某些表的數據後當更改操做發生的時候（update,delete,insert），纔會分配惟一的事務id,而且此事務id是遞增的，單純開啓事務是沒有事務id的，默認爲0，creator_trx_id是0。
• 如下例子中的A,B,C的意思是將姓名更改成A,B,C 讀也是讀取當前時刻的姓名,默認全都開啓事務,而且此事務都經歷過某些操做產生了事務id

讀已提交（RC）與MVCC

• 一個事務提交以後，它作的變動纔會被其餘事務看到

每次讀的時候，ReadView(一致性視圖)都會從新生成

1. 當T1時刻時，事務100修更名字爲A
2. 當T2時刻時，事務100修更名字爲B
3. 當T3時刻時，事務200修更名字爲C
4. 當T4時刻時，事務300開始讀取名字

• 此時這條數據的版本鏈以下

同顏色表明是同一事務內的操做

• 來咱們靜下心來好好分析一下此時T4時刻事務300要讀了，究竟會讀到什麼數據？

當前最近的一條數據是，C，事務200修改的，還記得咱們前文說的一致性視圖的幾個屬性嗎，和按照什麼規則判斷這個數據能不能被當前事務讀。咱們就分析這個例子。

此時  （生成一致性視圖ReadView）

• m_ids 是[100,200]： 當前活躍的讀寫事務的事務id列表
• min_trx_id 是 100：  m_ids的最小值
• max_trx_id 是 201： m_ids的最大值+1

當前數據的trx_id(事務id)是 200，符合min_trx_id<=trx_id<max_trx_id 此時須要判斷 trx_id 是否在m_ids活躍事務列表裏面，一看，活躍事務列表裏面是【100，200】，只有兩個事務活躍，而此時的trx_id是200，則trx_id在活躍事務列表裏面，活躍事務列表表明還未提交的事務，因此該版本數據不可見，就要根據roll_point指針指向上一個版本，繼續這樣的判斷，上一個版本事務id是100，數據是B，發現100也在活躍事務列表裏面，因此不可見，繼續找到上個版本，事務是100，數據是A，發現是一樣的狀況，繼續找到上個版本，發現事務是1，數據是小杰，1小於100，trx_id<min_trx_id，表明生成這個數據的事務已經在生成ReadView前提交了，此數據能夠被讀到。因此讀取的數據就是小杰。

分析完第一個讀，咱們繼續向下分析

1. 當T5時刻時，事務100提交
2. 當T6時刻時，事務300將名字改成D
3. 當T7時刻時，事務400讀取當前數據

• 此時這條數據的版本鏈以下

此時 （從新生成一致性視圖ReadView）

• m_ids 是[200,300]： 當前活躍的讀寫事務的事務id列表
• min_trx_id 是 200：  m_ids的最小值
• max_trx_id 是 301： m_ids的最大值+1

當前數據事務id是300，數據爲D，符合min_trx_id<=trx_id<max_trx_id 此時須要判斷數據是否在活躍事務列表裏，300在這裏面，因此就是還未提交的事務就是不可見，因此就去查看上個版本的數據，上個版本事務id是200，數據是C，也在活躍事務列表裏面，也不可見，繼續向上個版本找，上個版本事務id是100，數據是B，100小於min_trx_id，就表明，表明生成這個數據的事務已經在生成ReadView前提交了，此數據可見，因此讀取出來的數據就是B。

分析完第二個讀，咱們繼續向下分析

1. 當T8時刻時，事務200將名字改成E
2. 當T9時刻時，事務200提交
3. 當T10時刻時，事務300讀取當前數據

• 此時這條數據的版本鏈以下

此時 （從新生成一致性視圖ReadView）

• m_ids 是[300]： 當前活躍的讀寫事務的事務id列表
• min_trx_id 是 300：  m_ids的最小值
• max_trx_id 是 301： m_ids的最大值+1

當前事務id是200，200<min_trx_id ,表明生成這個數據的事務已經在生成ReadView前提交了，此數據可見，因此讀出的數據就是E。

當隔離級別是讀已提交RC的狀況下，每次讀都會從新生成 一致性視圖（ReadView）

• T4時刻 事務300讀取到的數據是小杰
• T7時刻 事務400讀取到的數據是B
• T10時刻 事務300讀取到的數據是E

可重複讀（RR）與MVCC

• 一個事務執行過程當中看到的數據，老是跟這個事務在啓動時看到的數據是一致的

因此對於事務300來說，它分別在T4和T10的時候，讀取數據，可是它的一致性視圖， 用的永遠都是第一次讀取時的視圖，就是T3時刻產生的一致性視圖

RR和RC的版本鏈是同樣的，可是判斷當前數據可見與否用到的一致性視圖不同

在此可重複讀RR隔離級別下，

1. T4時刻時事務300第一次讀時的分析和結果與RC都同樣，能夠見上文分析與結果
2. T7時刻時事務400第一次讀時的分析和結果與RC都同樣，能夠見上文分析與結果
3. T10時刻時事務300第二次讀時的一致性視圖和第一次讀時的同樣，因此此時到底讀取到什麼數據就要從新分析了

此時  （用的是第一次讀時生成的一致性視圖ReadView）

• m_ids 是[100,200]： 當前活躍的讀寫事務的事務id列表
• min_trx_id 是 100：  m_ids的最小值
• max_trx_id 是 201： m_ids的最大值+1

此時的版本鏈是

當前數據的事務id是200，數據是E，在當前事務活躍列表裏面，因此數據不可見，根據回滾指針找到上個版本，發現事務id是300，當前事務也是300，可見，因此讀取的數據是D

• 咱們能夠本身思考下，要是沒有事務300這條更改的這條記錄，又該怎麼繼續向下分析呢？

當隔離級別是可重複讀RR的狀況下，每次讀都會用第一次讀取數據時生成的一致性視圖（ReadView）

• T4時刻 事務300讀取到的數據是小杰
• T7時刻 事務400讀取到的數據是B
• T10時刻 事務300讀取到的數據是D

歡迎點擊【京東科技】，瞭解開發者社區

更多精彩技術實踐與獨家乾貨解析

歡迎關注【京東科技開發者】公衆號