小編給大家分享一下數(shù)據(jù)庫(kù)MVCC是什么，希望大家閱讀完這篇文章后大所收獲，下面讓我們一起去探討吧！

成都創(chuàng)新互聯(lián)公司是一家集網(wǎng)站建設(shè),灣里企業(yè)網(wǎng)站建設(shè),灣里品牌網(wǎng)站建設(shè),網(wǎng)站定制,灣里網(wǎng)站建設(shè)報(bào)價(jià),網(wǎng)絡(luò)營(yíng)銷,網(wǎng)絡(luò)優(yōu)化,灣里網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強(qiáng)企業(yè)競(jìng)爭(zhēng)力。可充分滿足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時(shí)我們時(shí)刻保持專業(yè)、時(shí)尚、前沿，時(shí)刻以成就客戶成長(zhǎng)自我，堅(jiān)持不斷學(xué)習(xí)、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實(shí)用型網(wǎng)站。

什么是MVCC

全稱Multi-Version Concurrency Control，即多版本并發(fā)控制，主要是為了提高數(shù)據(jù)庫(kù)的并發(fā)性能。以下文章都是圍繞InnoDB引擎來(lái)講，因?yàn)閙yIsam不支持事務(wù)。

同一行數(shù)據(jù)平時(shí)發(fā)生讀寫請(qǐng)求時(shí)，會(huì)上鎖阻塞住。但mvcc用更好的方式去處理讀—寫請(qǐng)求，做到在發(fā)生讀—寫請(qǐng)求沖突時(shí)不用加鎖。

這個(gè)讀是指的快照讀，而不是當(dāng)前讀，當(dāng)前讀是一種加鎖操作，是悲觀鎖。

那它到底是怎么做到讀—寫不用加鎖的，快照讀和當(dāng)前讀又是什么鬼，跟著你們的貼心老哥，繼續(xù)往下看。

當(dāng)前讀、快照讀都是什么鬼

什么是MySQL InnoDB下的當(dāng)前讀和快照讀？

當(dāng)前讀

它讀取的數(shù)據(jù)庫(kù)記錄，都是當(dāng)前最新的版本，會(huì)對(duì)當(dāng)前讀取的數(shù)據(jù)進(jìn)行加鎖，防止其他事務(wù)修改數(shù)據(jù)。是悲觀鎖的一種操作。

如下操作都是當(dāng)前讀：

• select lock in share mode (共享鎖)

• select for update (排他鎖)

• update (排他鎖)

• insert (排他鎖)

• delete (排他鎖)

• 串行化事務(wù)隔離級(jí)別

快照讀

快照讀的實(shí)現(xiàn)是基于多版本并發(fā)控制，即MVCC，既然是多版本，那么快照讀讀到的數(shù)據(jù)不一定是當(dāng)前最新的數(shù)據(jù)，有可能是之前歷史版本的數(shù)據(jù)。

如下操作是快照讀：

• 不加鎖的select操作（注：事務(wù)級(jí)別不是串行化）

快照讀與mvcc的關(guān)系

MVCCC是“維持一個(gè)數(shù)據(jù)的多個(gè)版本，使讀寫操作沒(méi)有沖突”的一個(gè)抽象概念。

這個(gè)概念需要具體功能去實(shí)現(xiàn)，這個(gè)具體實(shí)現(xiàn)就是快照讀。（具體實(shí)現(xiàn)下面講）

聽(tīng)完貼心老哥的講解，是不是瞬間茅廁頓開。

數(shù)據(jù)庫(kù)并發(fā)場(chǎng)景

• 讀-讀：不存在任何問(wèn)題，也不需要并發(fā)控制

• 讀-寫：有線程安全問(wèn)題，可能會(huì)造成事務(wù)隔離性問(wèn)題，可能遇到臟讀，幻讀，不可重復(fù)讀

• 寫-寫：有線程安全問(wèn)題，可能會(huì)存在更新丟失問(wèn)題，比如第一類更新丟失，第二類更新丟失

MVCC解決并發(fā)哪些問(wèn)題？

mvcc用來(lái)解決讀—寫沖突的無(wú)鎖并發(fā)控制，就是為事務(wù)分配單向增長(zhǎng)的時(shí)間戳。為每個(gè)數(shù)據(jù)修改保存一個(gè)版本，版本與事務(wù)時(shí)間戳相關(guān)聯(lián)。

讀操作只讀取該事務(wù)開始前的數(shù)據(jù)庫(kù)快照。

解決問(wèn)題如下：

• 并發(fā)讀-寫時(shí)：可以做到讀操作不阻塞寫操作，同時(shí)寫操作也不會(huì)阻塞讀操作。

• 解決臟讀、幻讀、不可重復(fù)讀等事務(wù)隔離問(wèn)題，但不能解決上面的寫-寫 更新丟失問(wèn)題。

因此有了下面提高并發(fā)性能的組合拳：

• MVCC + 悲觀鎖：MVCC解決讀寫沖突，悲觀鎖解決寫寫沖突

• MVCC + 樂(lè)觀鎖：MVCC解決讀寫沖突，樂(lè)觀鎖解決寫寫沖突

MVCC的實(shí)現(xiàn)原理

它的實(shí)現(xiàn)原理主要是版本鏈，undo日志 ，Read View 來(lái)實(shí)現(xiàn)的

版本鏈

我們數(shù)據(jù)庫(kù)中的每行數(shù)據(jù)，除了我們?nèi)庋劭匆?jiàn)的數(shù)據(jù)，還有幾個(gè)隱藏字段，得開天眼才能看到。分別是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，回滾指針，指向這條記錄的上一個(gè)版本（存儲(chǔ)于rollback segment里）

• db_row_id

  6byte，隱含的自增ID（隱藏主鍵），如果數(shù)據(jù)表沒(méi)有主鍵，InnoDB會(huì)自動(dòng)以db_row_id產(chǎn)生一個(gè)聚簇索引。

• 實(shí)際還有一個(gè)刪除flag隱藏字段, 記錄被更新或刪除并不代表真的刪除，而是刪除flag變了

如上圖，db_row_id是數(shù)據(jù)庫(kù)默認(rèn)為該行記錄生成的唯一隱式主鍵，db_trx_id是當(dāng)前操作該記錄的事務(wù)ID，而db_roll_pointer是一個(gè)回滾指針，用于配合undo日志，指向上一個(gè)舊版本。

每次對(duì)數(shù)據(jù)庫(kù)記錄進(jìn)行改動(dòng)，都會(huì)記錄一條undo日志，每條undo日志也都有一個(gè)roll_pointer屬性（INSERT操作對(duì)應(yīng)的undo日志沒(méi)有該屬性，因?yàn)樵撚涗洸](méi)有更早的版本），可以將這些undo日志都連起來(lái)，串成一個(gè)鏈表，所以現(xiàn)在的情況就像下圖一樣：

對(duì)該記錄每次更新后，都會(huì)將舊值放到一條undo日志中，就算是該記錄的一個(gè)舊版本，隨著更新次數(shù)的增多，所有的版本都會(huì)被roll_pointer屬性連接成一個(gè)鏈表，我們把這個(gè)鏈表稱之為版本鏈，版本鏈的頭節(jié)點(diǎn)就是當(dāng)前記錄最新的值。另外，每個(gè)版本中還包含生成該版本時(shí)對(duì)應(yīng)的事務(wù)id，這個(gè)信息很重要，在根據(jù)ReadView判斷版本可見(jiàn)性的時(shí)候會(huì)用到。

undo日志

Undo log 主要用于記錄數(shù)據(jù)被修改之前的日志，在表信息修改之前先會(huì)把數(shù)據(jù)拷貝到undo log里。

當(dāng)事務(wù)進(jìn)行回滾時(shí)可以通過(guò)undo log 里的日志進(jìn)行數(shù)據(jù)還原。

Undo log 的用途

• 保證事務(wù)進(jìn)行rollback時(shí)的原子性和一致性，當(dāng)事務(wù)進(jìn)行回滾的時(shí)候可以用undo log的數(shù)據(jù)進(jìn)行恢復(fù)。

• 用于MVCC快照讀的數(shù)據(jù)，在MVCC多版本控制中，通過(guò)讀取undo log的歷史版本數(shù)據(jù)可以實(shí)現(xiàn)不同事務(wù)版本號(hào)都擁有自己獨(dú)立的快照數(shù)據(jù)版本。

undo log主要分為兩種：

• insert undo log

  代表事務(wù)在insert新記錄時(shí)產(chǎn)生的undo log , 只在事務(wù)回滾時(shí)需要，并且在事務(wù)提交后可以被立即丟棄

• update undo log（主要）

  事務(wù)在進(jìn)行update或delete時(shí)產(chǎn)生的undo log ; 不僅在事務(wù)回滾時(shí)需要，在快照讀時(shí)也需要；

  所以不能隨便刪除，只有在快速讀或事務(wù)回滾不涉及該日志時(shí)，對(duì)應(yīng)的日志才會(huì)被purge線程統(tǒng)一清除

Read View(讀視圖)

事務(wù)進(jìn)行快照讀操作的時(shí)候生產(chǎn)的讀視圖(Read View)，在該事務(wù)執(zhí)行的快照讀的那一刻，會(huì)生成數(shù)據(jù)庫(kù)系統(tǒng)當(dāng)前的一個(gè)快照。

記錄并維護(hù)系統(tǒng)當(dāng)前活躍事務(wù)的ID(沒(méi)有commit，當(dāng)每個(gè)事務(wù)開啟時(shí)，都會(huì)被分配一個(gè)ID, 這個(gè)ID是遞增的，所以越新的事務(wù)，ID值越大)，是系統(tǒng)中當(dāng)前不應(yīng)該被本事務(wù)看到的其他事務(wù)id列表。

Read View主要是用來(lái)做可見(jiàn)性判斷的, 即當(dāng)我們某個(gè)事務(wù)執(zhí)行快照讀的時(shí)候，對(duì)該記錄創(chuàng)建一個(gè)Read View讀視圖，把它比作條件用來(lái)判斷當(dāng)前事務(wù)能夠看到哪個(gè)版本的數(shù)據(jù)，既可能是當(dāng)前最新的數(shù)據(jù)，也有可能是該行記錄的undo log里面的某個(gè)版本的數(shù)據(jù)。

Read View幾個(gè)屬性

• trx_ids: 當(dāng)前系統(tǒng)活躍(未提交)事務(wù)版本號(hào)集合。

• low_limit_id: 創(chuàng)建當(dāng)前read view 時(shí)“當(dāng)前系統(tǒng)最大事務(wù)版本號(hào)+1”。

• up_limit_id: 創(chuàng)建當(dāng)前read view 時(shí)“系統(tǒng)正處于活躍事務(wù)最小版本號(hào)”

• creator_trx_id: 創(chuàng)建當(dāng)前read view的事務(wù)版本號(hào)；

Read View可見(jiàn)性判斷條件

• db_trx_id < up_limit_id || db_trx_id == creator_trx_id（顯示）

  如果數(shù)據(jù)事務(wù)ID小于read view中的最小活躍事務(wù)ID，則可以肯定該數(shù)據(jù)是在當(dāng)前事務(wù)啟之前就已經(jīng)存在了的,所以可以顯示。

  或者數(shù)據(jù)的事務(wù)ID等于creator_trx_id ，那么說(shuō)明這個(gè)數(shù)據(jù)就是當(dāng)前事務(wù)自己生成的，自己生成的數(shù)據(jù)自己當(dāng)然能看見(jiàn)，所以這種情況下此數(shù)據(jù)也是可以顯示的。

• db_trx_id >= low_limit_id（不顯示）

  如果數(shù)據(jù)事務(wù)ID大于read view 中的當(dāng)前系統(tǒng)的最大事務(wù)ID，則說(shuō)明該數(shù)據(jù)是在當(dāng)前read view 創(chuàng)建之后才產(chǎn)生的，所以數(shù)據(jù)不顯示。如果小于則進(jìn)入下一個(gè)判斷

• db_trx_id是否在活躍事務(wù)（trx_ids）中

  • 不存在：則說(shuō)明read view產(chǎn)生的時(shí)候事務(wù)已經(jīng)commit了，這種情況數(shù)據(jù)則可以顯示。

  • 已存在：則代表我Read View生成時(shí)刻，你這個(gè)事務(wù)還在活躍，還沒(méi)有Commit，你修改的數(shù)據(jù)，我當(dāng)前事務(wù)也是看不見(jiàn)的。

MVCC和事務(wù)隔離級(jí)別

上面所講的Read View用于支持RC（Read Committed，讀提交）和RR（Repeatable Read，可重復(fù)讀）隔離級(jí)別的實(shí)現(xiàn)。

RR、RC生成時(shí)機(jī)

• RC隔離級(jí)別下，是每個(gè)快照讀都會(huì)生成并獲取最新的Read View；

• 而在RR隔離級(jí)別下，則是同一個(gè)事務(wù)中的第一個(gè)快照讀才會(huì)創(chuàng)建Read View, 之后的快照讀獲取的都是同一個(gè)Read View，之后的查詢就不會(huì)重復(fù)生成了，所以一個(gè)事務(wù)的查詢結(jié)果每次都是一樣的。

解決幻讀問(wèn)題

• 快照讀：通過(guò)MVCC來(lái)進(jìn)行控制的，不用加鎖。按照MVCC中規(guī)定的“語(yǔ)法”進(jìn)行增刪改查等操作，以避免幻讀。

• 當(dāng)前讀：通過(guò)next-key鎖（行鎖+gap鎖）來(lái)解決問(wèn)題的。

RC、RR級(jí)別下的InnoDB快照讀區(qū)別

• 在RR級(jí)別下的某個(gè)事務(wù)的對(duì)某條記錄的第一次快照讀會(huì)創(chuàng)建一個(gè)快照及Read View， 將當(dāng)前系統(tǒng)活躍的其他事務(wù)記錄起來(lái)，此后在調(diào)用快照讀的時(shí)候，還是使用的是同一個(gè)Read View，所以只要當(dāng)前事務(wù)在其他事務(wù)提交更新之前使用過(guò)快照讀，那么之后的快照讀使用的都是同一個(gè)Read View，所以對(duì)之后的修改不可見(jiàn)；

• 即RR級(jí)別下，快照讀生成Read View時(shí)，Read View會(huì)記錄此時(shí)所有其他活動(dòng)事務(wù)的快照，這些事務(wù)的修改對(duì)于當(dāng)前事務(wù)都是不可見(jiàn)的。而早于Read View創(chuàng)建的事務(wù)所做的修改均是可見(jiàn)

• 而在RC級(jí)別下的，事務(wù)中，每次快照讀都會(huì)新生成一個(gè)快照和Read View, 這就是我們?cè)赗C級(jí)別下的事務(wù)中可以看到別的事務(wù)提交的更新的原因

總結(jié)

從以上的描述中我們可以看出來(lái)，所謂的MVCC指的就是在使用READ COMMITTD、REPEATABLE READ這兩種隔離級(jí)別的事務(wù)在執(zhí)行普通的SEELCT操作時(shí)訪問(wèn)記錄的版本鏈的過(guò)程，這樣子可以使不同事務(wù)的讀-寫、寫-讀操作并發(fā)執(zhí)行，從而提升系統(tǒng)性能。

看完了這篇文章，相信你對(duì)數(shù)據(jù)庫(kù)MVCC是什么有了一定的了解，想了解更多相關(guān)知識(shí)，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝各位的閱讀！