本篇文章給大家?guī)?lái)了關(guān)于MySQL事務(wù)與MVCC如何實(shí)現(xiàn)的隔離級(jí)別的相關(guān)問(wèn)題，希望對(duì)大家有幫助。

數(shù)據(jù)庫(kù)事務(wù)介紹

事務(wù)的四大特性（ACID）

1. 原子性(atomicity)： 事務(wù)的最小工作單元，要么全成功，要么全失敗。

2. 一致性(consistency)： 事務(wù)開(kāi)始和結(jié)束后，數(shù)據(jù)庫(kù)的完整性不會(huì)被破壞。

3. 隔離性(isolation)： 不同事務(wù)之間互不影響，四種隔離級(jí)別為RU（讀未提交）、RC（讀已提交）、RR（可重復(fù)讀）、SERIALIZABLE （串行化）。

4. 持久性(durability)： 事務(wù)提交后，對(duì)數(shù)據(jù)的修改是永久性的，即使系統(tǒng)故障也不會(huì)丟失。

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

讀未提交（Read UnCommitted/RU）

又稱(chēng)為臟讀，一個(gè)事務(wù)可以讀取到另一個(gè)事務(wù)未提交的數(shù)據(jù)。這種隔離級(jí)別歲最不安全的一種，因?yàn)槲刺峤坏氖聞?wù)是存在回滾的情況。

讀已提交（Read Committed/RC）

又稱(chēng)為不可重復(fù)讀，一個(gè)事務(wù)因?yàn)樽x取到另一個(gè)事務(wù)已提交的修改數(shù)據(jù)，導(dǎo)致在當(dāng)前事務(wù)的不同時(shí)間讀取同一條數(shù)據(jù)獲取的結(jié)果不一致。

舉個(gè)例子，在下面的例子中就會(huì)發(fā)現(xiàn)SessionA在一個(gè)事務(wù)期間兩次查詢(xún)的數(shù)據(jù)不一樣。原因就是在于當(dāng)前隔離級(jí)別為 RC，SessionA的事務(wù)可以讀取到SessionB提交的最新數(shù)據(jù)。

可重復(fù)讀（Repeatable Read/RR）

又稱(chēng)為幻讀，一個(gè)事物讀可以讀取到其他事務(wù)提交的數(shù)據(jù)，但是在RR隔離級(jí)別下，當(dāng)前讀取此條數(shù)據(jù)只可讀取一次，在當(dāng)前事務(wù)中，不論讀取多少次，數(shù)據(jù)任然是第一次讀取的值，不會(huì)因?yàn)樵诘谝淮巫x取之后，其他事務(wù)再修改提交此數(shù)據(jù)而產(chǎn)生改變。因此也成為幻讀，因?yàn)樽x出來(lái)的數(shù)據(jù)并不一定就是最新的數(shù)據(jù)。

舉個(gè)例子：在SessionA中第一次讀取數(shù)據(jù)時(shí)，后續(xù)其他事務(wù)修改提交數(shù)據(jù)，不會(huì)再影響到SessionA讀取的數(shù)據(jù)值。此為可重復(fù)讀。

串行化（Serializable）

所有的數(shù)據(jù)庫(kù)的讀或者寫(xiě)操作都為串行執(zhí)行，當(dāng)前隔離級(jí)別下只支持單個(gè)請(qǐng)求同時(shí)執(zhí)行，所有的操作都需要隊(duì)列執(zhí)行。所以種隔離級(jí)別下所有的數(shù)據(jù)是最穩(wěn)定的，但是性能也是最差的。數(shù)據(jù)庫(kù)的鎖實(shí)現(xiàn)就是這種隔離級(jí)別的更小粒度版本。

事務(wù)和MVCC原理

不同事務(wù)同時(shí)操作同一條數(shù)據(jù)產(chǎn)生的問(wèn)題

示例：

上面的兩種情況就是對(duì)于一條數(shù)據(jù)，多個(gè)事務(wù)同時(shí)操作可能會(huì)產(chǎn)生的問(wèn)題，會(huì)出現(xiàn)某個(gè)事務(wù)的操作被覆蓋而導(dǎo)致數(shù)據(jù)丟失。

LBCC 解決數(shù)據(jù)丟失

LBCC，基于鎖的并發(fā)控制，Lock Based Concurrency Control。

使用鎖的機(jī)制，在當(dāng)前事務(wù)需要對(duì)數(shù)據(jù)修改時(shí)，將當(dāng)前事務(wù)加上鎖，同一個(gè)時(shí)間只允許一條事務(wù)修改當(dāng)前數(shù)據(jù)，其他事務(wù)必須等待鎖釋放之后才可以操作。

MVCC 解決數(shù)據(jù)丟失

MVCC，多版本的并發(fā)控制，Multi-Version Concurrency Control。

使用版本來(lái)控制并發(fā)情況下的數(shù)據(jù)問(wèn)題，在B事務(wù)開(kāi)始修改賬戶(hù)且事務(wù)未提交時(shí)，當(dāng)A事務(wù)需要讀取賬戶(hù)余額時(shí)，此時(shí)會(huì)讀取到B事務(wù)修改操作之前的賬戶(hù)余額的副本數(shù)據(jù)，但是如果A事務(wù)需要修改賬戶(hù)余額數(shù)據(jù)就必須要等待B事務(wù)提交事務(wù)。

MVCC使得數(shù)據(jù)庫(kù)讀不會(huì)對(duì)數(shù)據(jù)加鎖，普通的SELECT請(qǐng)求不會(huì)加鎖，提高了數(shù)據(jù)庫(kù)的并發(fā)處理能力。借助MVCC，數(shù)據(jù)庫(kù)可以實(shí)現(xiàn)READ COMMITTED，REPEATABLE READ等隔離級(jí)別，用戶(hù)可以查看當(dāng)前數(shù)據(jù)的前一個(gè)或者前幾個(gè)歷史版本，保證了ACID中的I特性（隔離性)。

InnoDB的MVCC實(shí)現(xiàn)邏輯

InnoDB存儲(chǔ)引擎保存的MVCC的數(shù)據(jù)

InnoDB的MVCC是通過(guò)在每行記錄后面保存兩個(gè)隱藏的列來(lái)實(shí)現(xiàn)的。一個(gè)保存了行的事務(wù)ID（DB_TRX_ID），一個(gè)保存了行的回滾指針（DB_ROLL_PT）。每開(kāi)始一個(gè)新的事務(wù)，都會(huì)自動(dòng)遞增產(chǎn) 生一個(gè)新的事務(wù)id。事務(wù)開(kāi)始時(shí)刻的會(huì)把事務(wù)id放到當(dāng)前事務(wù)影響的行事務(wù)id中，當(dāng)查詢(xún)時(shí)需要用當(dāng)前事務(wù)id和每行記錄的事務(wù)id進(jìn)行比較。

下面看一下在REPEATABLE READ隔離級(jí)別下，MVCC具體是如何操作的。

SELECT

InnoDB 會(huì)根據(jù)以下兩個(gè)條件檢查每行記錄：

1. InnoDB只查找版本早于當(dāng)前事務(wù)版本的數(shù)據(jù)行（也就是，行的事務(wù)編號(hào)小于或等于當(dāng)前事務(wù)的事務(wù)編號(hào)），這樣可以確保事務(wù)讀取的行，要么是在事務(wù)開(kāi)始前已經(jīng)存在的，要么是事務(wù)自身插入或者修改過(guò)的。

2. 刪除的行要事務(wù)ID判斷，讀取到事務(wù)開(kāi)始之前狀態(tài)的版本，只有符合上述兩個(gè)條件的記錄，才能返回作為查詢(xún)結(jié)果。

INSERT

InnoDB為新插入的每一行保存當(dāng)前事務(wù)編號(hào)作為行版本號(hào)。

DELETE

InnoDB為刪除的每一行保存當(dāng)前事務(wù)編號(hào)作為行刪除標(biāo)識(shí)。

UPDATE

InnoDB為插入一行新記錄，保存當(dāng)前事務(wù)編號(hào)作為行版本號(hào)，同時(shí)保存當(dāng)前事務(wù)編號(hào)到原來(lái)的行作為行刪除標(biāo)識(shí)。

保存這兩個(gè)額外事務(wù)編號(hào)，使大多數(shù)讀操作都可以不用加鎖。這樣設(shè)計(jì)使得讀數(shù)據(jù)操作很簡(jiǎn)單，性能很好，并且也能保證只會(huì)讀取到符合標(biāo)準(zhǔn)的行。不足之處是每行記錄都需要額外的存儲(chǔ)空間，需要做