一 MVCC的作用

1.1 mvcc的作用

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

2.mysql中的InnoDB中實(shí)現(xiàn)了MVCC主要是為了提高數(shù)據(jù)庫(kù)的并發(fā)性能，在無鎖的情況下也能處理讀寫并發(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)臟寫的情況，也就是不會(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ā)性能，用更好的方式處理讀寫沖突，做到即使有讀寫沖突，也能不加鎖實(shí)現(xiàn)非堵塞并發(fā)讀，這個(gè)讀指的是快照讀而不是當(dāng)前讀。

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

1.3 快照讀

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

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

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

1.4?當(dāng)前讀

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

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

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

1.5 mvcc可以解決問題

1. 讀寫之間的堵塞問題，提高事務(wù)的并發(fā)讀寫能力

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

3. 解決快照讀問題，當(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ā)控制，通過生成記錄的歷史版本解決幻讀問題，并提高數(shù)據(jù)庫(kù)的性能，無鎖實(shí)現(xiàn)讀寫并發(fā)操作。

1.mvcc 的實(shí)現(xiàn)主要是通過三個(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ù)的可見性。

5.描述readView 可見性判斷規(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日志通過回滾指針串聯(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ǔ)引擎的表來說，它的聚簇記錄中包含兩個(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ì)將舊的版本信息寫入undo log中，通過回滾指針就能找到記錄修改前的信息。

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)椴迦霙]有更新的版本），這些undo log通過roll pointer連接起來，串成一個(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ù)表中沒有主鍵，那么InnoDB會(huì)自動(dòng)生成單調(diào)遞增的隱藏主鍵（表中有主鍵或者非NULL的UNIQUE鍵時(shí)都不會(huì)包含 DB_ROW_ID列）。

如上面的表沒有設(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ù)的可見性，當(dāng)某個(gè)事務(wù)執(zhí)行快照讀的時(shí)候，會(huì)對(duì)此記錄創(chuàng)建一個(gè)ReadView 的視圖，在整個(gè)事務(wù)期間根據(jù)某些條件判斷該事務(wù)能夠看到的版本鏈上的哪條歷史數(shù)據(jù)。

2.4.2? ReadView的組成

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

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

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

4. 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)

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

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

1.如果Read View的creator_id和當(dāng)前事務(wù)的id相同，則意味著當(dāng)前事務(wù)在訪問它修改過的id，所以該記錄版本可以被事務(wù)訪問

2.如果當(dāng)前訪問版本記錄的trx_id小于Read View的up_limit_id，則意味著修改該數(shù)據(jù)版本的事務(wù)已經(jīng)提交，所以該版本的記錄可以被當(dāng)前事務(wù)訪問

3.如果當(dāng)前訪問版本記錄的trx_id大于等于Read View的low_limit_id，則意味著創(chuàng)建該數(shù)據(jù)版本的事務(wù)是在ReadView生成之后才出現(xiàn)的，因此當(dāng)前事務(wù)不能訪問

4.如果當(dāng)前訪問版本記錄的trx_id在Read View的up_limit_id和low_limit_id之間，則需要判斷trx_id是否在Read View的trx_ids活躍事務(wù)列表中，如果在則說明事務(wù)還沒有提交當(dāng)前事務(wù)不能訪問，否則可以訪問

5.如果某個(gè)版本對(duì)當(dāng)前事務(wù)不可見，那么順著版本鏈找到下個(gè)版本記錄，然后繼續(xù)上面的對(duì)比規(guī)則，直到找到版本鏈中的最后一個(gè)版本，如果最后一個(gè)版本都不可見，那么該條記錄對(duì)此事務(wù)完全不可見，也就查不到這個(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ī)定使用加鎖的方式來訪問記錄，通過加鎖的方式讓所有sql都串行化執(zhí)行了，也是讀最新的，不存在快照讀ReadView。

https://www.cnblogs.com/tod4/p/17384677.html

MySQL進(jìn)階系列：多版本并發(fā)控制mvcc的實(shí)現(xiàn)

2.6? mvcc解決幻讀問題

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

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

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

2.6.1 mvcc解決幻讀

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

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

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

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

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

2.6.2 通過加鎖的方式

讀、寫操作都采用加鎖的方式

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

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

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

到了這里，關(guān)于mysql的mvcc詳解的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！