新聞中心
大家好,我是來自JDL京東物流技術(shù)發(fā)展部邢煥杰, 今天來分享一個京東面試真題,這也是我前陣子聽我工位旁邊高T(高,實在是高)面試候選人的時候問的一個問題,他問,你能說說 MySQL的事務(wù)嗎?MVCC有了解嗎?話不多說,本文就深度解析一下MySQL事務(wù)及MVCC的實現(xiàn)原理。

我們提供的服務(wù)有:成都網(wǎng)站制作、網(wǎng)站建設(shè)、外貿(mào)網(wǎng)站建設(shè)、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認(rèn)證、方正ssl等。為1000多家企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務(wù),是有科學(xué)管理、有技術(shù)的方正網(wǎng)站制作公司
事務(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) 層面實現(xiàn)的,用來處理讀寫沖突的手段(不用加鎖),提高訪問性能
MVCC是怎么實現(xiàn)的呢?它靠的就是版本鏈和一致性視圖
1. 版本鏈
- 版本鏈?zhǔn)且粭l鏈表,鏈接的是每條數(shù)據(jù)曾經(jīng)的修改記錄
那么這個版本鏈又是如何形成的呢,每條數(shù)據(jù)又是靠什么鏈接起來的呢?
其實是這樣的,對于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ù):
所以此時的版本鏈如下:
我們每更改一次數(shù)據(jù),就會插入一條undo日志,并且記錄的roll_pointer指針會指向上一條記錄,如圖所示:
- 第一條數(shù)據(jù)是小杰,事務(wù)ID為100
- 事務(wù)ID為200的事務(wù)將名稱從小杰改為了A
- 事務(wù)ID為200的事務(wù)將名稱從A又改為了B
- 事務(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ī)不一樣 (這也是兩種隔離級別實現(xiàn)的主要區(qū)別)
- 讀提交(read committed RC) 是在 每一次select的時候生成ReadView的
- 可重復(fù)讀(repeatable read RR)是在 第一次select的時候生成ReadView的
下面咱們一起來舉個例子實戰(zhàn)一下。
RR與RC和MVCC的例子實戰(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
讀已提交(RC)與MVCC
一個事務(wù)提交之后,它做的變更才會被其他事務(wù)看到
每次讀的時候,ReadView(一致性視圖)都會重新生成
- 當(dāng)T1時刻時,事務(wù)100修改名字為A
- 當(dāng)T2時刻時,事務(wù)100修改名字為B
- 當(dāng)T3時刻時,事務(wù)200修改名字為C
- 當(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ù)向下分析
此時這條數(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_id
分析完第二個讀,我們繼續(xù)向下分析
- 當(dāng)T8時刻時,事務(wù)200將名字改為E
- 當(dāng)T9時刻時,事務(wù)200提交
- 當(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,200
當(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隔離級別下,
- T4時刻時事務(wù)300第一次讀時的分析和結(jié)果與RC都一樣,可以見上文分析與結(jié)果
- T7時刻時事務(wù)400第一次讀時的分析和結(jié)果與RC都一樣,可以見上文分析與結(jié)果
- 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
網(wǎng)站欄目:我身邊的高T,問了Java面試者這樣的問題......
文章鏈接:http://www.5511xx.com/article/ccsiics.html


咨詢
建站咨詢
