小編給大家分享一下數(shù)據(jù)庫MVCC是什么,希望大家閱讀完這篇文章后大所收獲,下面讓我們一起去探討吧!
創(chuàng)新互聯(lián)建站專注于仙游企業(yè)網(wǎng)站建設(shè),響應(yīng)式網(wǎng)站,電子商務(wù)商城網(wǎng)站建設(shè)。仙游網(wǎng)站建設(shè)公司,為仙游等地區(qū)提供建站服務(wù)。全流程按需求定制制作,專業(yè)設(shè)計,全程項目跟蹤,創(chuàng)新互聯(lián)建站專業(yè)和態(tài)度為您提供的服務(wù)全稱Multi-Version Concurrency Control,即多版本并發(fā)控制
,主要是為了提高數(shù)據(jù)庫的并發(fā)性能
。以下文章都是圍繞InnoDB引擎來講,因為myIsam不支持事務(wù)。
同一行數(shù)據(jù)平時發(fā)生讀寫請求時,會上鎖阻塞
住。但mvcc用更好的方式去處理讀—寫請求,做到在發(fā)生讀—寫請求沖突時不用加鎖
。
這個讀是指的快照讀
,而不是當前讀
,當前讀是一種加鎖操作,是悲觀鎖
。
那它到底是怎么做到讀—寫不用加鎖
的,快照讀
和當前讀
又是什么鬼,跟著你們的貼心老哥
,繼續(xù)往下看。
什么是MySQL InnoDB下的當前讀和快照讀?
它讀取的數(shù)據(jù)庫記錄,都是當前最新
的版本
,會對當前讀取的數(shù)據(jù)進行加鎖
,防止其他事務(wù)修改數(shù)據(jù)。是悲觀鎖
的一種操作。
如下操作都是當前讀:
select lock in share mode (共享鎖)
select for update (排他鎖)
update (排他鎖)
insert (排他鎖)
delete (排他鎖)
串行化事務(wù)隔離級別
快照讀的實現(xiàn)是基于多版本
并發(fā)控制,即MVCC,既然是多版本,那么快照讀讀到的數(shù)據(jù)不一定是當前最新的數(shù)據(jù),有可能是之前歷史版本
的數(shù)據(jù)。
如下操作是快照讀:
MVCCC
是“維持一個數(shù)據(jù)的多個版本,使讀寫操作沒有沖突”的一個抽象概念
。
這個概念需要具體功能去實現(xiàn),這個具體實現(xiàn)就是快照讀
。(具體實現(xiàn)下面講)
聽完貼心老哥
的講解,是不是瞬間茅廁頓開
。
讀-讀
:不存在任何問題,也不需要并發(fā)控制
讀-寫
:有線程安全問題,可能會造成事務(wù)隔離性問題,可能遇到臟讀,幻讀,不可重復讀
寫-寫
:有線程安全問題,可能會存在更新丟失問題,比如第一類更新丟失,第二類更新丟失
mvcc用來解決讀—寫沖突的無鎖并發(fā)控制,就是為事務(wù)分配單向增長
的時間戳
。為每個數(shù)據(jù)修改保存一個版本
,版本與事務(wù)時間戳相關(guān)聯(lián)
。
讀操作只讀取
該事務(wù)開始前
的數(shù)據(jù)庫快照
。
解決問題如下:
并發(fā)讀-寫時
:可以做到讀操作不阻塞寫操作,同時寫操作也不會阻塞讀操作。
解決臟讀
、幻讀
、不可重復讀
等事務(wù)隔離問題,但不能解決上面的寫-寫 更新丟失
問題。
因此有了下面提高并發(fā)性能的組合拳
:
MVCC + 悲觀鎖
:MVCC解決讀寫沖突,悲觀鎖解決寫寫沖突
MVCC + 樂觀鎖
:MVCC解決讀寫沖突,樂觀鎖解決寫寫沖突
它的實現(xiàn)原理主要是版本鏈
,undo日志
,Read View
來實現(xiàn)的
我們數(shù)據(jù)庫中的每行數(shù)據(jù),除了我們?nèi)庋劭匆姷臄?shù)據(jù),還有幾個隱藏字段
,得開天眼
才能看到。分別是db_trx_id
、db_roll_pointer
、db_row_id
。
db_trx_id
6byte,最近修改(修改/插入)事務(wù)ID
:記錄創(chuàng)建
這條記錄/最后一次修改
該記錄的事務(wù)ID
。
db_roll_pointer(版本鏈關(guān)鍵)
7byte,回滾指針
,指向這條記錄
的上一個版本
(存儲于rollback segment里)
db_row_id
6byte,隱含的自增ID
(隱藏主鍵),如果數(shù)據(jù)表沒有主鍵
,InnoDB會自動以db_row_id產(chǎn)生一個聚簇索引
。
實際還有一個刪除flag
隱藏字段, 記錄被更新
或刪除
并不代表真的刪除,而是刪除flag
變了
如上圖,db_row_id
是數(shù)據(jù)庫默認為該行記錄生成的唯一隱式主鍵
,db_trx_id
是當前操作該記錄的事務(wù)ID
,而db_roll_pointer
是一個回滾指針
,用于配合undo日志
,指向上一個舊版本
。
每次對數(shù)據(jù)庫記錄進行改動,都會記錄一條undo日志
,每條undo日志也都有一個roll_pointer
屬性(INSERT操作對應(yīng)的undo日志沒有該屬性,因為該記錄并沒有更早的版本),可以將這些undo日志都連起來
,串成一個鏈表
,所以現(xiàn)在的情況就像下圖一樣:
對該記錄每次更新后,都會將舊值放到一條undo日志中,就算是該記錄的一個舊版本,隨著更新次數(shù)的增多,所有的版本都會被roll_pointer
屬性連接成一個鏈表
,我們把這個鏈表稱之為版本鏈
,版本鏈的頭節(jié)點就是當前記錄最新的值。另外,每個版本中還包含生成該版本時對應(yīng)的事務(wù)id,這個信息很重要,在根據(jù)ReadView判斷版本可見性的時候會用到。
Undo log 主要用于記錄
數(shù)據(jù)被修改之前
的日志,在表信息修改之前先會把數(shù)據(jù)拷貝到undo log
里。
當事務(wù)
進行回滾時
可以通過undo log 里的日志進行數(shù)據(jù)還原
。
Undo log 的用途
保證事務(wù)
進行rollback
時的原子性和一致性
,當事務(wù)進行回滾
的時候可以用undo log的數(shù)據(jù)進行恢復
。
用于MVCC快照讀
的數(shù)據(jù),在MVCC多版本控制中,通過讀取undo log
的歷史版本數(shù)據(jù)
可以實現(xiàn)不同事務(wù)版本號
都擁有自己獨立的快照數(shù)據(jù)版本
。
undo log主要分為兩種:
insert undo log
代表事務(wù)在insert新記錄時產(chǎn)生的undo log , 只在事務(wù)回滾時需要,并且在事務(wù)提交后可以被立即丟棄
update undo log(主要)
事務(wù)在進行update或delete時產(chǎn)生的undo log ; 不僅在事務(wù)回滾時需要,在快照讀時也需要;
所以不能隨便刪除,只有在快速讀或事務(wù)回滾不涉及該日志時,對應(yīng)的日志才會被purge線程統(tǒng)一清除
事務(wù)進行快照讀
操作的時候生產(chǎn)的讀視圖
(Read View),在該事務(wù)執(zhí)行的快照讀的那一刻,會生成數(shù)據(jù)庫系統(tǒng)當前的一個快照
。
記錄并維護系統(tǒng)當前活躍事務(wù)的ID
(沒有commit,當每個事務(wù)開啟時,都會被分配一個ID, 這個ID是遞增的,所以越新的事務(wù),ID值越大),是系統(tǒng)中當前不應(yīng)該被本事務(wù)
看到的其他事務(wù)id列表
。
Read View主要是用來做可見性
判斷的, 即當我們某個事務(wù)
執(zhí)行快照讀
的時候,對該記錄創(chuàng)建一個Read View讀視圖,把它比作條件用來判斷當前事務(wù)
能夠看到哪個版本
的數(shù)據(jù),既可能是當前最新
的數(shù)據(jù),也有可能是該行記錄的undo log里面的某個版本
的數(shù)據(jù)。
Read View幾個屬性
trx_ids
: 當前系統(tǒng)活躍(未提交
)事務(wù)版本號集合。
low_limit_id
: 創(chuàng)建當前read view 時“當前系統(tǒng)大事務(wù)版本號
+1”。
up_limit_id
: 創(chuàng)建當前read view 時“系統(tǒng)正處于活躍事務(wù)最小版本號
”
creator_trx_id
: 創(chuàng)建當前read view的事務(wù)版本號;
db_trx_id
< up_limit_id
|| db_trx_id
== creator_trx_id
(顯示)
如果數(shù)據(jù)事務(wù)ID小于read view中的最小活躍事務(wù)ID
,則可以肯定該數(shù)據(jù)是在當前事務(wù)啟之前
就已經(jīng)存在
了的,所以可以顯示
。
或者數(shù)據(jù)的事務(wù)ID
等于creator_trx_id
,那么說明這個數(shù)據(jù)就是當前事務(wù)自己生成的
,自己生成的數(shù)據(jù)自己當然能看見,所以這種情況下此數(shù)據(jù)也是可以顯示
的。
db_trx_id
>= low_limit_id
(不顯示)
如果數(shù)據(jù)事務(wù)ID大于read view 中的當前系統(tǒng)的大事務(wù)ID
,則說明該數(shù)據(jù)是在當前read view 創(chuàng)建之后才產(chǎn)生
的,所以數(shù)據(jù)不顯示
。如果小于則進入下一個判斷
db_trx_id
是否在活躍事務(wù)
(trx_ids)中
不存在
:則說明read view產(chǎn)生的時候事務(wù)已經(jīng)commit
了,這種情況數(shù)據(jù)則可以顯示
。
已存在
:則代表我Read View生成時刻,你這個事務(wù)還在活躍,還沒有Commit,你修改的數(shù)據(jù),我當前事務(wù)也是看不見的。
上面所講的Read View
用于支持RC
(Read Committed,讀提交)和RR
(Repeatable Read,可重復讀)隔離級別
的實現(xiàn)
。
RC
隔離級別下,是每個快照讀
都會生成并獲取最新
的Read View
;
而在RR
隔離級別下,則是同一個事務(wù)中
的第一個快照讀
才會創(chuàng)建Read View
, 之后的
快照讀獲取的都是同一個Read View
,之后的查詢就不會重復生成
了,所以一個事務(wù)的查詢結(jié)果每次都是一樣的
。
快照讀
:通過MVCC來進行控制的,不用加鎖。按照MVCC中規(guī)定的“語法”進行增刪改查等操作,以避免幻讀。
當前讀
:通過next-key鎖(行鎖+gap鎖)來解決問題的。
在RR級別下的某個事務(wù)的對某條記錄的第一次快照讀會創(chuàng)建一個快照及Read View, 將當前系統(tǒng)活躍的其他事務(wù)記錄起來,此后在調(diào)用快照讀的時候,還是使用的是同一個Read View,所以只要當前事務(wù)在其他事務(wù)提交更新之前使用過快照讀,那么之后的快照讀使用的都是同一個Read View,所以對之后的修改不可見;
即RR級別下,快照讀生成Read View時,Read View會記錄此時所有其他活動事務(wù)的快照,這些事務(wù)的修改對于當前事務(wù)都是不可見的。而早于Read View創(chuàng)建的事務(wù)所做的修改均是可見
而在RC級別下的,事務(wù)中,每次快照讀都會新生成一個快照和Read View, 這就是我們在RC級別下的事務(wù)中可以看到別的事務(wù)提交的更新的原因
從以上的描述中我們可以看出來,所謂的MVCC指的就是在使用READ COMMITTD
、REPEATABLE READ
這兩種隔離級別的事務(wù)在執(zhí)行普通的SEELCT
操作時訪問記錄的版本鏈
的過程,這樣子可以使不同事務(wù)的讀-寫
、寫-讀
操作并發(fā)執(zhí)行
,從而提升系統(tǒng)性能
。
看完了這篇文章,相信你對數(shù)據(jù)庫MVCC是什么有了一定的了解,想了解更多相關(guān)知識,歡迎關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司行業(yè)資訊頻道,感謝各位的閱讀!