京東面試官問我:“聊聊MySql事務(wù),MVCC?”

大家好，我是java小杰要加油， 今天來分享一個京東面試真題，也是這是我前陣子聽我工位旁邊高T（高，實(shí)在是高）面試候選人的時候問的一個問題，他問，你能說說 mysql的事務(wù)嗎？MVCC有了解嗎？

• 話不多說，直接開干

事務(wù)定義及四大特性

• 事務(wù)是什么？

  就是用戶定義的一系列數(shù)據(jù)庫操作，這些操作可以視為一個完成的邏輯處理工作單元，要么全部執(zhí)行，要么全部不執(zhí)行，是不可分割的工作單元。

• 事務(wù)的四大特性（簡稱ACID）：

  • 原子性（Atomicity）：一個事務(wù)是一個不可分割的工作單位，事務(wù)中包括的操作要么都做，要么都不做。
  • 一致性（Consistency）：事務(wù)必須是使數(shù)據(jù)庫從一個一致性狀態(tài)變到另一個一致性狀態(tài)。一致性與原子性是密切相關(guān)的。
  • 隔離性（Isolation）：一個事務(wù)的執(zhí)行不能被其他事務(wù)干擾。即一個事務(wù)內(nèi)部的操作及使用的數(shù)據(jù)對并發(fā)的其他事務(wù)是隔離的，并發(fā)執(zhí)行的各個事務(wù)之間不能互相干擾.
  • 持久性（Durability）：指一個事務(wù)一旦提交，它對數(shù)據(jù)庫中數(shù)據(jù)的改變就應(yīng)該是永久性的,接下來的其他操作或故障不應(yīng)該對其有任何影響。

事務(wù)中常見問題

• 臟讀（dirty read）：就是一個A事務(wù)即便沒有提交，它對數(shù)據(jù)的修改也可以被其他事務(wù)B事務(wù)看到，B事務(wù)讀到了A事務(wù)還未提交的數(shù)據(jù)，這個數(shù)據(jù)有可能是錯的，有可能A不想提交這個數(shù)據(jù)，這只是A事務(wù)修改數(shù)據(jù)過程中的一個中間數(shù)據(jù)，但是被B事務(wù)讀到了，這種行為被稱作臟讀，這個數(shù)據(jù)被稱為臟數(shù)據(jù)

• 不可重復(fù)讀（non-repeatable read）：在A事務(wù)內(nèi)，多次讀取同一個數(shù)據(jù)，但是讀取的過程中，B事務(wù)對這個數(shù)據(jù)進(jìn)行了修改，導(dǎo)致此數(shù)據(jù)變化了，那么A事務(wù)再次讀取的時候，數(shù)據(jù)就和第一次讀取的時候不一樣了，這就叫做不可重復(fù)讀

• 幻讀（phantom read）：A事務(wù)多次查詢數(shù)據(jù)庫，結(jié)果發(fā)現(xiàn)查詢的數(shù)據(jù)條數(shù)不一樣，A事務(wù)多次查詢的間隔中，B事務(wù)又寫入了一些符合查詢條件的多條數(shù)據(jù)（這里的寫入可以是update，insert，delete），A事務(wù)再查的話，就像發(fā)生了幻覺一樣，怎么突然改變了這么多，這種現(xiàn)象這就叫做幻讀

隔離級別——產(chǎn)生問題的原因

多個事務(wù)互相影響，并沒有隔離好，就是我們剛才提到的事務(wù)的四大特性中的 隔離性（Isolation） 出現(xiàn)了問題 事務(wù)的隔離級別并沒有設(shè)置好，下面我們來看下事務(wù)究竟有哪幾種隔離級別

• 隔離級別
  • 讀未提交（read uncommitted RU）： 一個事務(wù)還沒提交時，它做的變更就能被別的事務(wù)看到
  • 讀提交（read committed RC）： 一個事務(wù)提交之后，它做的變更才會被其他事務(wù)看到。
  • 可重復(fù)讀（repeatable read RR）： 一個事務(wù)執(zhí)行過程中看到的數(shù)據(jù)，總是跟這個事務(wù)在啟動時看到的數(shù)據(jù)是一致的。當(dāng)然在可重復(fù)讀隔離級別下，未提交變更對其他事務(wù)也是不可見的。
  • 串行化（serializable ）： 顧名思義是對于同一行記錄，“寫”會加“寫鎖”，“讀”會加“讀鎖”。當(dāng)出現(xiàn)讀寫鎖沖突的時候，后訪問的事務(wù)必須等前一個事務(wù)執(zhí)行完成，才能繼續(xù)執(zhí)行。

我們來看個例子，更加直觀的了解這四種隔離級別和上述問題臟讀，不可重復(fù)讀，幻讀的關(guān)系

下面我們討論下當(dāng)事務(wù)處于不同隔離級別情況時，V1,V2,V3分別是什么不同的值吧

• 讀未提交 (RU)： A事務(wù)可以讀取到B事務(wù)修改的值，即便B事務(wù)沒有提交。所以V1就是200

  • V1 : 200
  • V2 : 200
  • V3 : 200

• 讀提交（RC）： 當(dāng)B事務(wù)沒有提交的時候，A事務(wù)不可以看到B事務(wù)修改的值，只有提交以后才可以看到

  • V1 : 100
  • V2 : 200
  • V3 : 200

• 可重復(fù)讀（RR）： A事務(wù)多次讀取數(shù)據(jù)，數(shù)據(jù)總和第一次讀取的一樣，

  • V1 : 100
  • V2 : 100
  • V3 : 200

• 串行化（S）： 事務(wù)A在執(zhí)行的時候，事務(wù)B會被鎖住，等事務(wù)A執(zhí)行結(jié)束后，事務(wù)B才可以繼續(xù)執(zhí)行

  • V1 : 100
  • V2 : 100
  • V3 : 200

MVCC原理

MVCC（Multi-Version Concurrency Control）多版本并發(fā)控制，是數(shù)據(jù)庫控制并發(fā)訪問的一種手段。

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

MVCC是怎么實(shí)現(xiàn)的呢？它靠的就是版本鏈和一致性視圖

1. 版本鏈

• 版本鏈?zhǔn)且粭l鏈表，鏈接的是每條數(shù)據(jù)曾經(jīng)的修改記錄

那么這個版本鏈又是如何形成的呢，每條數(shù)據(jù)又是靠什么鏈接起來的呢？

其實(shí)是這樣的，對于InnoDB存儲引擎的表來說，它的聚簇索引記錄包含兩個隱藏字段

• trx_id: 存儲修改此數(shù)據(jù)的事務(wù)id，只有這個事務(wù)操作了某些表的數(shù)據(jù)后當(dāng)更改操作發(fā)生的時候（update,delete,insert），才會分配唯一的事務(wù)id,并且此事務(wù)id是遞增的
• roll_pointer: 指針，指向上一次修改的記錄
• row_id(非必須): 當(dāng)有主鍵或者有不允許為null的unique鍵時，不包含此字段

假如說當(dāng)前數(shù)據(jù)庫有一條這樣的數(shù)據(jù)，假設(shè)是事務(wù)ID為100的事務(wù)插入的這條數(shù)據(jù)，那么此條數(shù)據(jù)的結(jié)構(gòu)如下

后來，事務(wù)200，事務(wù)300，分別來修改此數(shù)據(jù)

時間T	trx_id ?200	trx_id ?300
T1	開始事務(wù)	開始事務(wù)
T2	更改名字為A
T3	更改名字為B
T4	提交事務(wù)	更改名字為C
T6		提交事務(wù)

所以此時的版本鏈如下

我們每更改一次數(shù)據(jù)，就會插入一條undo日志，并且記錄的roll_pointer指針會指向上一條記錄，如圖所示

1. 第一條數(shù)據(jù)是小杰，事務(wù)ID為100
2. 事務(wù)ID為200的事務(wù)將名稱從小杰改為了A
3. 事務(wù)ID為200的事務(wù)將名稱從A又改為了B
4. 事務(wù)ID為300的事務(wù)將名稱從B又改為了C

所以串成的鏈表就是 C -> B -> A -> 小杰 （從最新的數(shù)據(jù)到最老的數(shù)據(jù)）

2. 一致性視圖（ReadView）

需要判斷版本鏈中的哪個版本是是當(dāng)前事務(wù)可見的，因此有了一致性視圖的概念。其中有四個屬性比較重要

• m_ids: 在生成ReadView時，當(dāng)前活躍的讀寫事務(wù)的事務(wù)id列表
• min_trx_id: m_ids的最小值
• max_trx_id: m_ids的最大值+1
• creator_trx_id: 生成該事務(wù)的事務(wù)id，單純開啟事務(wù)是沒有事務(wù)id的，默認(rèn)為0，creator_trx_id是0。

版本鏈中的當(dāng)前版本是否可以被當(dāng)前事務(wù)可見的要根據(jù)這四個屬性按照以下幾種情況來判斷

• 當(dāng) trx_id = creator_trx_id 時:當(dāng)前事務(wù)可以看見自己所修改的數(shù)據(jù)， 可見，
• 當(dāng) trx_id < min_trx_id 時 ? : 生成此數(shù)據(jù)的事務(wù)已經(jīng)在生成readView前提交了， 可見
• 當(dāng) ?trx_id >= max_trx_id 時 ? :表明生成該數(shù)據(jù)的事務(wù)是在生成ReadView后才開啟的， 不可見
• 當(dāng) ?min_trx_id <= trx_id < max_trx_id 時
  • trx_id 在 m_ids 列表里面 ：生成ReadView時，活躍事務(wù)還未提交，不可見
  • trx_id 不在 m_ids 列表里面 ：事務(wù)在生成readView前已經(jīng)提交了，可見

如果某個版本數(shù)據(jù)對當(dāng)前事務(wù)不可見，那么則要順著版本鏈繼續(xù)向前尋找下個版本，繼續(xù)這樣判斷，以此類推。

注：RR和RC生成一致性視圖的時機(jī)不一樣 （這也是兩種隔離級別實(shí)現(xiàn)的主要區(qū)別）

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

下面咱們一起來舉個例子實(shí)戰(zhàn)一下。

RR與RC和MVCC的例子實(shí)戰(zhàn)

假如說，我們有多個事務(wù)如下執(zhí)行，我們通過這個例子來分析當(dāng)數(shù)據(jù)庫隔離級別為RC和RR的情況下，當(dāng)時讀數(shù)據(jù)的一致性視圖和版本鏈，也就是MVCC，分別是怎么樣的。

• 假設(shè)數(shù)據(jù)庫中有一條初始數(shù)據(jù) ?姓名是java小杰要加油，id是1 （id,姓名,trx_id,roll_point），插入此數(shù)據(jù)的事務(wù)id是1
• 尤其要指出的是，只有這個事務(wù)操作了某些表的數(shù)據(jù)后當(dāng)更改操作發(fā)生的時候（update,delete,insert），才會分配唯一的事務(wù)id,并且此事務(wù)id是遞增的，單純開啟事務(wù)是沒有事務(wù)id的，默認(rèn)為0，creator_trx_id是0。
• 以下例子中的A,B,C的意思是將姓名更改為A,B,C 讀也是讀取當(dāng)前時刻的姓名,默認(rèn)全都開啟事務(wù),并且此事務(wù)都經(jīng)歷過某些操作產(chǎn)生了事務(wù)id

時間	事務(wù)100	事務(wù)200	事務(wù)300	事務(wù)400
T1	A
T2	B
T3		C
T4			讀
T5	提交
T6			D
T7				讀
T8		E
T9		提交
T10			讀

讀已提交（RC）與MVCC

• 一個事務(wù)提交之后，它做的變更才會被其他事務(wù)看到

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

1. 當(dāng)T1時刻時，事務(wù)100修改名字為A
2. 當(dāng)T2時刻時，事務(wù)100修改名字為B
3. 當(dāng)T3時刻時，事務(wù)200修改名字為C
4. 當(dāng)T4時刻時，事務(wù)300開始讀取名字

• 此時這條數(shù)據(jù)的版本鏈如下

同顏色代表是同一事務(wù)內(nèi)的操作

• 來我們靜下心來好好分析一下此時T4時刻事務(wù)300要讀了，究竟會讀到什么數(shù)據(jù)？

當(dāng)前最近的一條數(shù)據(jù)是，C，事務(wù)200修改的，還記得我們前文說的一致性視圖的幾個屬性嗎，和按照什么規(guī)則判斷這個數(shù)據(jù)能不能被當(dāng)前事務(wù)讀。我們就分析這個例子。

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

• m_ids 是[100,200]： 當(dāng)前活躍的讀寫事務(wù)的事務(wù)id列表
• min_trx_id 是 100： ?m_ids的最小值
• max_trx_id 是 201： m_ids的最大值+1

當(dāng)前數(shù)據(jù)的trx_id(事務(wù)id)是 200，符合min_trx_id<=trx_id小杰

分析完第一個讀，我們繼續(xù)向下分析

1. 當(dāng)T5時刻時，事務(wù)100提交
2. 當(dāng)T6時刻時，事務(wù)300將名字改為D
3. 當(dāng)T7時刻時，事務(wù)400讀取當(dāng)前數(shù)據(jù)

• 此時這條數(shù)據(jù)的版本鏈如下

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

• m_ids 是[200,300]： 當(dāng)前活躍的讀寫事務(wù)的事務(wù)id列表
• min_trx_id 是 200： ?m_ids的最小值
• max_trx_id 是 301： m_ids的最大值+1

當(dāng)前數(shù)據(jù)事務(wù)id是300，數(shù)據(jù)為D，符合min_trx_id<=trx_idB

分析完第二個讀，我們繼續(xù)向下分析

1. 當(dāng)T8時刻時，事務(wù)200將名字改為E
2. 當(dāng)T9時刻時，事務(wù)200提交
3. 當(dāng)T10時刻時，事務(wù)300讀取當(dāng)前數(shù)據(jù)

• 此時這條數(shù)據(jù)的版本鏈如下

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

• m_ids 是[300]： 當(dāng)前活躍的讀寫事務(wù)的事務(wù)id列表
• min_trx_id 是 300： ?m_ids的最小值
• max_trx_id 是 301： m_ids的最大值+1

當(dāng)前事務(wù)id是200，200E.

當(dāng)隔離級別是讀已提交RC的情況下，每次讀都會重新生成 一致性視圖（ReadView）

• T4時刻 事務(wù)300讀取到的數(shù)據(jù)是小杰
• T7時刻 事務(wù)400讀取到的數(shù)據(jù)是B
• T10時刻 事務(wù)300讀取到的數(shù)據(jù)是E

可重復(fù)讀（RR）與MVCC

• 一個事務(wù)執(zhí)行過程中看到的數(shù)據(jù)，總是跟這個事務(wù)在啟動時看到的數(shù)據(jù)是一致的

所以對于事務(wù)300來講，它分別在T4和T10的時候，讀取數(shù)據(jù)，但是它的一致性視圖，用的永遠(yuǎn)都是第一次讀取時的視圖，就是T3時刻產(chǎn)生的一致性視圖

RR和RC的版本鏈?zhǔn)且粯拥模桥袛喈?dāng)前數(shù)據(jù)可見與否用到的一致性視圖不一樣

在此可重復(fù)讀RR隔離級別下，

1. T4時刻時事務(wù)300第一次讀時的分析和結(jié)果與RC都一樣，可以見上文分析與結(jié)果
2. T7時刻時事務(wù)400第一次讀時的分析和結(jié)果與RC都一樣，可以見上文分析與結(jié)果
3. T10時刻時事務(wù)300第二次讀時的一致性視圖和第一次讀時的一樣，所以此時到底讀取到什么數(shù)據(jù)就要重新分析了

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

• m_ids 是[100,200]： 當(dāng)前活躍的讀寫事務(wù)的事務(wù)id列表
• min_trx_id 是 100： ?m_ids的最小值
• max_trx_id 是 201： m_ids的最大值+1

此時的版本鏈?zhǔn)?/p>

當(dāng)前數(shù)據(jù)的事務(wù)id是200，數(shù)據(jù)是E，在當(dāng)前事務(wù)活躍列表里面，所以數(shù)據(jù)不可見，根據(jù)回滾指針找到上個版本，發(fā)現(xiàn)事務(wù)id是300，當(dāng)前事務(wù)也是300，可見，所以讀取的數(shù)據(jù)是D

• 我們可以自己思考下，要是沒有事務(wù)300這條更改的這條記錄，又該怎么繼續(xù)向下分析呢？

當(dāng)隔離級別是可重復(fù)讀RR的情況下，每次讀都會用第一次讀取數(shù)據(jù)時生成的一致性視圖（ReadView）

• T4時刻 事務(wù)300讀取到的數(shù)據(jù)是小杰
• T7時刻 事務(wù)400讀取到的數(shù)據(jù)是B
• T10時刻 事務(wù)300讀取到的數(shù)據(jù)是D

往期精彩推薦

• 京東這道面試題你會嗎？
• ？線程池為什么可以復(fù)用，我是蒙圈了。。。
• 學(xué)會了volatile，你變心了，我看到了
• mysql可以靠索引，而我只能靠打工，加油，打工人！
• 你好，我叫AQS（系列一：加鎖）

絮絮叨叨

如果大家覺得這篇文章對自己有一點(diǎn)點(diǎn)幫助的話，歡迎關(guān)注此公眾號，小杰非常希望各位可以點(diǎn)擊一下屏幕下方的

點(diǎn)贊、在看、收藏、分享。

（劉關(guān)張直接在我嘴里結(jié)義）

• 隨手一個點(diǎn)擊，我將無法忘記，這是我堅持創(chuàng)作的最大動力！

• 非常歡迎 各位號主讀者一起交流學(xué)習(xí)，互相開白轉(zhuǎn)發(fā)，網(wǎng)絡(luò)一線牽，珍惜這段緣

若文章有誤歡迎指出，靚仔靚女們，我們下篇文章見，掃一掃，開啟我們的故事