一 MVCC的作用

1.1 mvcc的作用

1.MVCC（Multiversion Concurrency Control）多版本并發(fā)控制。即通過(guò)數(shù)據(jù)行的多個(gè)版本管理來(lái)實(shí)現(xiàn)數(shù)據(jù)庫(kù)的并發(fā)控制，使得在InnoDB事務(wù)隔離級(jí)別下執(zhí)行一致性讀操作有了保障。

2.mysql中的InnoDB中實(shí)現(xiàn)了MVCC主要是為了提高數(shù)據(jù)庫(kù)的并發(fā)性能，在無(wú)鎖的情況下也能處理讀寫(xiě)并發(fā)，大大提高數(shù)據(jù)庫(kù)的并發(fā)度。

3..MySQl中只有InnoDB支持MVCC，其他存儲(chǔ)引擎不支持

4.為了查詢一些正在被其他事務(wù)更新的值的時(shí)候，能夠查到它們被更新之前的值，這樣做就能在查詢的時(shí)候不必等待更新事務(wù)的提交。

在InnoDB中，會(huì)對(duì)增刪改操作自動(dòng)添加排它鎖，因此兩個(gè)事務(wù)不會(huì)出現(xiàn)臟寫(xiě)的情況，也就是不會(huì)出現(xiàn)兩個(gè)事務(wù)交叉著對(duì)同一條記錄進(jìn)行修改，必須等待第一個(gè)事務(wù)提交才能進(jìn)行第二個(gè)事務(wù)。

1.2 快照讀與當(dāng)前讀的區(qū)別與聯(lián)系

1.MVCC在InnoDB中的實(shí)現(xiàn)主要是為了提高數(shù)據(jù)庫(kù)的并發(fā)性能，用更好的方式處理讀寫(xiě)沖突，做到即使有讀寫(xiě)沖突，也能不加鎖實(shí)現(xiàn)非堵塞并發(fā)讀，這個(gè)讀指的是快照讀而不是當(dāng)前讀。

2.當(dāng)前讀實(shí)質(zhì)上是一種加鎖的操作，是悲觀鎖的體現(xiàn)；而MVCC是采用樂(lè)觀鎖的一種方式

1.3 快照讀

1.快照讀，顧名思義讀取的是一份快照數(shù)據(jù)，所以讀到的并不一定是最新數(shù)據(jù)，可能是歷史數(shù)據(jù)。

2.簡(jiǎn)單的select查詢就是快照讀，不加鎖非阻塞讀，降低數(shù)據(jù)庫(kù)的開(kāi)銷(xiāo)。

3.但是快照讀在隔離級(jí)別是串行化級(jí)別是沒(méi)有意義的，因?yàn)榇谢膕ql都是排隊(duì)執(zhí)行的，不存在并發(fā)，所以就會(huì)變成當(dāng)前讀。

1.4 當(dāng)前讀

當(dāng)前讀獲取的數(shù)據(jù)是最新數(shù)據(jù)，而且在讀取時(shí)不能被其他修改的，所以會(huì)對(duì)讀取的記錄加鎖來(lái)控制。

加鎖的SELECT（共享或排它鎖）或者對(duì)數(shù)據(jù)進(jìn)行增刪改操作（自動(dòng)添加排它鎖）都會(huì)進(jìn)行當(dāng)前讀。

select * from ajisun where id > 1 lock in share mode;</code><code>// 或者</code><code>select * from ajisun where id >1 for update;

1.5 mvcc可以解決問(wèn)題

• 讀寫(xiě)之間的堵塞問(wèn)題，提高事務(wù)的并發(fā)讀寫(xiě)能力

• 降低了死鎖的概率，MVCC采用了樂(lè)觀鎖的方式，讀取數(shù)據(jù)的時(shí)候不需要加鎖，對(duì)于寫(xiě)操作，也只要鎖定必要的行

• 解決快照讀問(wèn)題，當(dāng)查詢數(shù)據(jù)庫(kù)某個(gè)時(shí)間節(jié)點(diǎn)的快照的時(shí)候，只能查看到在這個(gè)節(jié)點(diǎn)之前提交的事務(wù)的結(jié)果而看不到時(shí)間點(diǎn)之后事務(wù)提交的更新結(jié)果

1.6 mvcc面試題：mvcc是怎么實(shí)現(xiàn)的

mvcc 是多版本并發(fā)控制，通過(guò)生成記錄的歷史版本解決幻讀問(wèn)題，并提高數(shù)據(jù)庫(kù)的性能，無(wú)鎖實(shí)現(xiàn)讀寫(xiě)并發(fā)操作。

1.mvcc 的實(shí)現(xiàn)主要是通過(guò)三個(gè)隱藏字段，undo log以及readView 實(shí)現(xiàn)的。

2.三個(gè)隱藏字段分別是隱藏主鍵，事務(wù)ID，回滾指針。

3.undo log是各個(gè)事務(wù)修改同一條記錄的時(shí)候生成的歷史記錄，方便回滾，同時(shí)會(huì)生成一條版本鏈。

4.readView是事務(wù)在進(jìn)行快照讀的時(shí)候生成的記錄快照，用于判斷數(shù)據(jù)的可見(jiàn)性。

5.描述readView 可見(jiàn)性判斷規(guī)則。

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

2.1 原理

? MVCC的實(shí)現(xiàn)依賴于：隱藏字段、Undo log、Read View 

2.2 undo log

2.2.1 undo Log的作用

所謂的版本鏈就是在MVCC中，多個(gè)事務(wù)對(duì)同一行記錄進(jìn)行更新會(huì)產(chǎn)生多個(gè)歷史快照，這些記錄保存在Undo Log里，這些undo日志通過(guò)回滾指針串聯(lián)在一起。

undo log就是回滾日志，在insert/update/delete變更操作的時(shí)候生成的記錄方便回滾。

當(dāng)進(jìn)行insert操作的時(shí)候，產(chǎn)生的undo log只有在事務(wù)回滾的時(shí)候需要，如果不回滾在事務(wù)提交之后就會(huì)被刪除。

當(dāng)進(jìn)行update和delete的時(shí)候，產(chǎn)生的undo log不僅僅在事務(wù)回滾的時(shí)候需要，在快照讀的時(shí)候也是需要的，所以不會(huì)立即刪除，只有等不再用到這個(gè)日志的時(shí)候才會(huì)被mysql purge線程統(tǒng)一處理掉（delete操作也只是打一個(gè)刪除標(biāo)記，并不是真正的刪除)。

2.2.2 undo Log的組成

? undo log的版本鏈，對(duì)于使用InnoDB存儲(chǔ)引擎的表來(lái)說(shuō)，它的聚簇記錄中包含兩個(gè)必要的索引列：

1.trx_id：每次事務(wù)對(duì)聚簇記錄進(jìn)行修改的時(shí)候，就會(huì)將該事務(wù)的id復(fù)制給trx_id隱藏列

2.roll_pointer：每次對(duì)每條聚簇索引進(jìn)行改動(dòng)的時(shí)候，都會(huì)將舊的版本信息寫(xiě)入undo log中，通過(guò)回滾指針就能找到記錄修改前的信息。

2.2.3 undo Log的案例

1.假設(shè)兩個(gè)事務(wù)id分別為10、20的事務(wù)分別對(duì)這條記錄進(jìn)行Update操作。

2.每次對(duì)記錄進(jìn)行改動(dòng)，都會(huì)記錄一條undo log，每個(gè)undo log都包含創(chuàng)建它的事務(wù)id，每條undo log都會(huì)有一個(gè)roll pointer（INSERT操作不會(huì)有，因?yàn)椴迦霙](méi)有更新的版本），這些undo log通過(guò)roll pointer連接起來(lái)，串成一個(gè)鏈表，這個(gè)鏈表就成為undo log 版本鏈。

3.如下圖：

2.3 隱藏字段

除了我們正常業(yè)務(wù)涉及的字段外，InnoDB在內(nèi)部向數(shù)據(jù)庫(kù)表中添加三個(gè)隱藏字段:

1.DB_TRX_ID：6-byte的事務(wù)ID。插入或更新行的最后一個(gè)事務(wù)的事務(wù)ID

2.DB_ROLL_PTR：7-byte的回滾指針。就是指向?qū)?yīng)某行記錄的上一個(gè)版本，在undo log中使用。

3.DB_ROW_ID：6-byte的隱藏主鍵。如果數(shù)據(jù)表中沒(méi)有主鍵，那么InnoDB會(huì)自動(dòng)生成單調(diào)遞增的隱藏主鍵（表中有主鍵或者非NULL的UNIQUE鍵時(shí)都不會(huì)包含 DB_ROW_ID列）。

如上面的表沒(méi)有設(shè)計(jì)primary key,其中id/name/city是我們的業(yè)務(wù)字段，那么加上隱藏字段應(yīng)該如下

2.4  ReadView

2.4.1 ReadView的作用

ReadView 是事務(wù)快照讀的時(shí)候產(chǎn)生的數(shù)據(jù)讀視圖，在該事務(wù)執(zhí)行快照讀的那一刻，會(huì)生成一個(gè)數(shù)據(jù)系統(tǒng)當(dāng)前的快照，記錄并維護(hù)系統(tǒng)當(dāng)前活躍事務(wù)的id，事務(wù)的id值是遞增的。

Read View就是事務(wù)在使用MVCC機(jī)制在進(jìn)行快照讀操作時(shí)產(chǎn)生的快照，ReadView 的最大作用就是判斷數(shù)據(jù)的可見(jiàn)性，當(dāng)某個(gè)事務(wù)執(zhí)行快照讀的時(shí)候，會(huì)對(duì)此記錄創(chuàng)建一個(gè)ReadView 的視圖，在整個(gè)事務(wù)期間根據(jù)某些條件判斷該事務(wù)能夠看到的版本鏈上的哪條歷史數(shù)據(jù)。

2.4.2  ReadView的組成

• creator_id：創(chuàng)建這個(gè)Read View的事務(wù)id

• trx_ids：表示創(chuàng)建這個(gè)Read View的時(shí)候正在活躍的事務(wù)id列表

• up_limit_id：活躍的事務(wù)中最小的id

• low_limit_id：表示生成low_limit_id時(shí)系統(tǒng)應(yīng)該分配給下一個(gè)事務(wù)的id值，low_limit_id是系統(tǒng)最大的事務(wù)id（而不是活躍的最大事務(wù)id）

low_limit_id  并不是trx_ids的最大值，而是系統(tǒng)能夠分配的事務(wù)id最大值，事務(wù)id是遞增分配的，并且只有事務(wù)在進(jìn)行增刪改操作的時(shí)候才會(huì)分配事務(wù)ID。比如現(xiàn)在有1 2 5三個(gè)事務(wù)，那么id為5的事務(wù)提交后，一個(gè)新事務(wù)在生成ReadView的時(shí)候，trx_ids就包括1 2，up_limit_id就是1，low_limit_id就是6

此時(shí)如果有事務(wù)創(chuàng)建Read View，則

• trx_ids=[trx2, trx3, trx5, trx8]
• up_limit_id=trx2
• low_limit_id=trx8+1

2.4.3  ReadView的判斷流程

當(dāng)查詢一條數(shù)據(jù)的時(shí)候，系統(tǒng)

• 首先獲取查詢操作的事務(wù)的版本號(hào)
• 獲取當(dāng)前系統(tǒng)的ReadView
• 將查詢到的數(shù)據(jù)與ReadView中的事務(wù)版本號(hào)進(jìn)行比較
• 如果不符合ReadView的規(guī)則，則通過(guò)回滾指針形成的Undo Log版本鏈從undo log中獲取符合規(guī)則的歷史快照
• 返回符合規(guī)則的數(shù)據(jù)

快照記錄創(chuàng)建這個(gè)Read View的事務(wù)id、活躍的事務(wù)中最小的id、系統(tǒng)最大的事務(wù)id，并且InnoDB會(huì)為每個(gè)事務(wù)構(gòu)建了一個(gè)數(shù)組，用來(lái)記錄并維護(hù)系統(tǒng)當(dāng)前活躍事務(wù)的ID（活躍指的是啟動(dòng)了還沒(méi)有提交），等到訪問(wèn)某條記錄的時(shí)候，就可以根據(jù)上面記錄的內(nèi)容判斷記錄版本對(duì)當(dāng)前事務(wù)可不可見(jiàn)：

1.如果當(dāng)前被訪問(wèn)記錄的trx_id屬性值與ReadView中的creator_trx_id值相同，說(shuō)明當(dāng)前事務(wù)修改的記錄就是在當(dāng)前事務(wù)下操作的，那當(dāng)然是對(duì)我們可見(jiàn)的了，因此可以修改這條記錄

2.如果當(dāng)前被訪問(wèn)記錄的trx_id屬性值小于ReadView中up_limit_id值，說(shuō)明(生成該版本的事務(wù)在該事務(wù)生成readView之間已經(jīng)提交)    即當(dāng)前事務(wù)在開(kāi)啟的時(shí)候，這條記錄最近依次被其他事務(wù)操作的事務(wù)已經(jīng)提交了，所以對(duì)這條記錄對(duì)我們來(lái)說(shuō)也是可以見(jiàn)，可以修改

3.如果當(dāng)前被訪問(wèn)記錄的trx_id屬性值大于或者等于ReadView中l(wèi)ow_limit_id值，說(shuō)明(生成該版本的事務(wù)在當(dāng)前事務(wù)生成readView之后才開(kāi)啟)     即：我們開(kāi)啟事務(wù)未修改該記錄之前，已經(jīng)有另外一個(gè)事務(wù)開(kāi)啟，并且正在修改該事務(wù)了，因此，這條記錄對(duì)我們來(lái)說(shuō)依然是不可見(jiàn)的，我們不能修改。

4.如果當(dāng)前被訪問(wèn)記錄的trx_id屬性值介于ReadView中 up_limit_id 和 low_limit_id 之間的話，那么此時(shí)就需要分情況討論了，此時(shí)我們應(yīng)該分析該trx_id是否在 trx_ids 中

如果存在，說(shuō)明(創(chuàng)建ReadView時(shí)，生成該版本的事務(wù)還處于活躍狀態(tài))    即：當(dāng)前已經(jīng)有其它的事務(wù)正在修改該條記錄，并且還未提交，此時(shí)這條記錄對(duì)我們不可見(jiàn)

如果不存在，說(shuō)明((創(chuàng)建ReadView時(shí)，生成該版本的事務(wù)已經(jīng)提交)   即：此時(shí)沒(méi)有事務(wù)操作該條記錄，我們可以修改該條記錄

5.如果某個(gè)版本對(duì)當(dāng)前事務(wù)不可見(jiàn)，那么順著版本鏈找到下個(gè)版本記錄，然后繼續(xù)上面的對(duì)比規(guī)則，直到找到版本鏈中的最后一個(gè)版本，如果最后一個(gè)版本都不可見(jiàn)，那么該條記錄對(duì)此事務(wù)完全不可見(jiàn)，也就查不到這個(gè)記錄。

2.5 不同隔離級(jí)別使用Readview

1.讀未提交：能夠讀取未提交的事務(wù)修改的數(shù)據(jù)，所以直接讀取最新的記錄就可以，不必使用MVCC

2.讀已提交：不能讀取未提交的事務(wù)修改的數(shù)據(jù)，并且不能進(jìn)行重復(fù)讀取，事務(wù)中，每次快照讀都會(huì)新生成一個(gè)快照和ReadView,這就是我們?cè)赗C級(jí)別下的事務(wù)中可以看到別的事務(wù)提交的更新的原因。

3.可重復(fù)讀：不能讀取未提交的事務(wù)修改的數(shù)據(jù)，并且能進(jìn)行重復(fù)讀取，所以只在第一次查詢的時(shí)候獲取一次ReadView，之后查詢都只查看已經(jīng)生成的ReadView副本

4.可串行化：InnoDB規(guī)定使用加鎖的方式來(lái)訪問(wèn)記錄，通過(guò)加鎖的方式讓所有sql都串行化執(zhí)行了，也是讀最新的，不存在快照讀ReadView。

2.6  mvcc解決幻讀問(wèn)題

MySQL在Repeatable Read隔離級(jí)別下是可以解決幻讀問(wèn)題的，解決的方案有兩種：

1.使用MVCC進(jìn)行快照讀，寫(xiě)使用臨鍵鎖。添加的臨鍵鎖不會(huì)影響快照讀，只會(huì)影響到想要獲取鎖的讀操作

2.讀寫(xiě)加鎖，也就是使用可串行化的隔離模式。

2.6.1 mvcc解決幻讀

讀操作利用多版本并發(fā)控制（MVCC），寫(xiě)操作加鎖。

MVCC就是生成一個(gè)ReadView，通過(guò)ReadView能夠找到符合條件的記錄版本（歷史版本由undo log提供查詢），查詢語(yǔ)句執(zhí)行查詢已經(jīng)提交的事務(wù)做出的更改，對(duì)于沒(méi)由提交的事務(wù)和ReadView創(chuàng)建之后的事務(wù)做出的更改是看不到的。而寫(xiě)操作肯定是針對(duì)的最新版本的記錄，因此讀記錄的歷史版本和寫(xiě)操作的最新記錄版本并不會(huì)沖突，也就是采用MVCC時(shí)，讀寫(xiě)操作并不會(huì)沖突。

普通的SELECT語(yǔ)句在READ COMMITTED 和 REPEATABLE READ隔離級(jí)別下的讀操作就是利用MVCC進(jìn)行的讀

1.READ COMMITTED：由于不會(huì)讀取沒(méi)有提交的事務(wù)修改的數(shù)據(jù)版本，因此避免了臟讀問(wèn)題

2.REPEATABLE READ：由于不會(huì)讀取Read View創(chuàng)建之后的事務(wù)更改的數(shù)據(jù)(一個(gè)事務(wù)只有在第一次執(zhí)行SELECT語(yǔ)句才會(huì)生成一個(gè)Read View，之后的SELECT語(yǔ)句都在復(fù)用)，因此避免了可重復(fù)讀和幻讀問(wèn)題。

2.6.2 通過(guò)加鎖的方式

讀、寫(xiě)操作都采用加鎖的方式

在一些業(yè)務(wù)場(chǎng)景中，不允許讀取數(shù)據(jù)的歷史版本，即每次都需要去讀取磁盤(pán)中最新的數(shù)據(jù)，這樣也就意味著讀操作也需要和寫(xiě)操作一樣排隊(duì)執(zhí)行。

如此一來(lái)，臟讀和不可重復(fù)讀問(wèn)題都得到了解決，因?yàn)樽x操作和寫(xiě)操作的串行執(zhí)行，不會(huì)出現(xiàn)一個(gè)事務(wù)讀取另一個(gè)未提交事務(wù)的數(shù)據(jù)以及一個(gè)事務(wù)讀取過(guò)程中另一個(gè)事務(wù)修改數(shù)據(jù)提交導(dǎo)致前一個(gè)事務(wù)前后讀取數(shù)據(jù)不一致的情況（第二個(gè)事務(wù)根本無(wú)法開(kāi)始）。

****但是，幻讀問(wèn)題有些尷尬，試想一個(gè)事務(wù)在進(jìn)行讀操作，因此給表中的一定范圍內(nèi)的數(shù)據(jù)加鎖，但是另一個(gè)事務(wù)要寫(xiě)的這個(gè)幻影數(shù)據(jù)可不在這個(gè)范圍里面，也就是兩個(gè)讀寫(xiě)操作并不會(huì)沖突，仍然會(huì)出現(xiàn)幻讀問(wèn)題，解決這一個(gè)問(wèn)題的辦法就是寫(xiě)操作使用臨鍵鎖

到此這篇關(guān)于mysql中mvcc的具體使用的文章就介紹到這了,更多相關(guān)mysql mvcc內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論