這篇文章給大家介紹MySQL事務(wù)與MVCC怎么實(shí)現(xiàn)隔離級(jí)別，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對(duì)大家能有所幫助。

成都一家集口碑和實(shí)力的網(wǎng)站建設(shè)服務(wù)商，擁有專業(yè)的企業(yè)建站團(tuán)隊(duì)和靠譜的建站技術(shù)，十多年企業(yè)及個(gè)人網(wǎng)站建設(shè)經(jīng)驗(yàn) ,為成都近1000家客戶提供網(wǎng)頁(yè)設(shè)計(jì)制作,網(wǎng)站開發(fā),企業(yè)網(wǎng)站制作建設(shè)等服務(wù),包括成都營(yíng)銷型網(wǎng)站建設(shè)，品牌網(wǎng)站建設(shè)，同時(shí)也為不同行業(yè)的客戶提供成都網(wǎng)站設(shè)計(jì)、成都做網(wǎng)站、外貿(mào)網(wǎng)站建設(shè)的服務(wù),包括成都電商型網(wǎng)站制作建設(shè),裝修行業(yè)網(wǎng)站制作建設(shè)，傳統(tǒng)機(jī)械行業(yè)網(wǎng)站建設(shè),傳統(tǒng)農(nóng)業(yè)行業(yè)網(wǎng)站制作建設(shè)。在成都做網(wǎng)站,選網(wǎng)站制作建設(shè)服務(wù)商就選創(chuàng)新互聯(lián)公司。

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

介紹事務(wù)的四大特性(ACID)

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

2. 一致性(consistency)： 事務(wù)開始和結(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)

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

讀已提交(Read Committed/RC)

又稱為不可重復(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ù)期間兩次查詢的數(shù)據(jù)不一樣。原因就是在于當(dāng)前隔離級(jí)別為  RC，SessionA的事務(wù)可以讀取到SessionB提交的最新數(shù)據(jù)。

發(fā)生時(shí)間	SessionA	SessionB
1	begin;
2	select * from user where id=1;(張三)
3		update user set name='李四' where id=1;(默認(rèn)隱式提交事務(wù))
4	select * from user where id=1;(李四)
5		update user set name='王二' where id=1;(默認(rèn)隱式提交事務(wù))
6	select * from user where id=1;(王二)

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

又稱為幻讀，一個(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ù)讀。

發(fā)生時(shí)間	SessionA	SessionB
1	begin;
2	select * from user where id=1;(張三)
3		update user set name='李四' where id=1;  (默認(rèn)隱式提交事務(wù))
4	select * from user where id=1;(張三)
5		update user set name='王二' where id=1;(默認(rèn)隱式提交事務(wù))
6	select * from user where id=1;(張三)

串行化(Serializable)

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

發(fā)生時(shí)間	SessionA	SessionB
1	begin;
2		begin;
3		update user set name='李四' where id=1;
4	select * from user where id=1;(等待、wait)
5		commit；
6	select * from user where id=1;(李四)

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

示例：

發(fā)生時(shí)間	SessionA	SessionB
1	begin;
2		begin;
3		查詢余額 = 1000元
4	查詢余額 = 1000元
5		存入金額 100元，修改余額為 1100元
6	取出現(xiàn)金100元，此時(shí)修改余額為900元
8		提交事務(wù)（余額=1100）
9	提交事務(wù)（余額=900）

發(fā)生時(shí)間	SessionA	SessionB
1	begin;
2		begin;
3		查詢余額 = 1000元
4	查詢余額 = 1000元
5		存入金額 100元，修改余額為 1100元
6	取出現(xiàn)金100元，此時(shí)修改余額為900元
8		提交事務(wù)（余額=1100）
9	撤銷事務(wù)（余額恢復(fù)為1000元）

上面的兩種情況就是對(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ù)開始修改賬戶且事務(wù)未提交時(shí)，當(dāng)A事務(wù)需要讀取賬戶余額時(shí)，此時(shí)會(huì)讀取到B事務(wù)修改操作之前的賬戶余額的副本數(shù)據(jù)，但是如果A事務(wù)需要修改賬戶余額數(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í)別，用戶可以查看當(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)。每開始一個(gè)新的事務(wù)，都會(huì)自動(dòng)遞增產(chǎn)  生一個(gè)新的事務(wù)id。事務(wù)開始時(shí)刻的會(huì)把事務(wù)id放到當(dāng)前事務(wù)影響的行事務(wù)id中，當(dāng)查詢時(shí)需要用當(dāng)前事務(wù)id和每行記錄的事務(wù)id進(jìn)行比較。

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

SELECT

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

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

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

3. 刪除的行要事務(wù)ID判斷，讀取到事務(wù)開始之前狀態(tài)的版本，只有符合上述兩個(gè)條件的記錄，才能返回作為查詢結(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ǔ)空間，需要做更多的行檢查工作，以及一些額外的維護(hù)工作。

MVCC只在REPEATABLE READ和READ COMMITIED兩個(gè)隔離級(jí)別下工作。其他兩個(gè)隔離級(jí)別都和 MVCC不兼容 ，因?yàn)镽EAD  UNCOMMITIED總是讀取最新的數(shù)據(jù)行，而不是符合當(dāng)前事務(wù)版本的數(shù)據(jù)行。而SERIALIZABLE則會(huì)對(duì)所有讀取的行都加鎖。

MVCC 在mysql 中的實(shí)現(xiàn)依賴的是 undo log 與 read view 。

undo log

根據(jù)行為的不同，undo log分為兩種：insert undo log 和 update undo log

• insert undo log：

insert 操作中產(chǎn)生的undo log，因?yàn)閕nsert操作記錄只對(duì)當(dāng)前事務(wù)本身課件，對(duì)于其他事務(wù)此記錄不可見，所以 insert undo log  可以在事務(wù)提交后直接刪除而不需要進(jìn)行purge操作。

purge的主要任務(wù)是將數(shù)據(jù)庫(kù)中已經(jīng) mark del 的數(shù)據(jù)刪除，另外也會(huì)批量回收undo pages

數(shù)據(jù)庫(kù) Insert時(shí)的數(shù)據(jù)初始狀態(tài)：

• update undo log：

update 或 delete 操作中產(chǎn)生的 undo log。因?yàn)闀?huì)對(duì)已經(jīng)存在的記錄產(chǎn)生影響，為了提供 MVCC機(jī)制，因此update undo log  不能在事務(wù)提交時(shí)就進(jìn)行刪除，而是將事務(wù)提交時(shí)放到入 history list 上，等待 purge 線程進(jìn)行最后的刪除操作。

數(shù)據(jù)第一次被修改時(shí)：

當(dāng)另一個(gè)事務(wù)第二次修改當(dāng)前數(shù)據(jù)：

為了保證事務(wù)并發(fā)操作時(shí)，在寫各自的undo log時(shí)不產(chǎn)生沖突，InnoDB采用回滾段的方式來(lái)維護(hù)undo log的并發(fā)寫入和持久化?；貪L段實(shí)際上是一種  Undo 文件組織方式。

ReadView

對(duì)于 RU(READ UNCOMMITTED) 隔離級(jí)別下，所有事務(wù)直接讀取數(shù)據(jù)庫(kù)的最新值即可，和 SERIALIZABLE  隔離級(jí)別，所有請(qǐng)求都會(huì)加鎖，同步執(zhí)行。所以這對(duì)這兩種情況下是不需要使用到 Read View 的版本控制。

對(duì)于 RC(READ COMMITTED) 和 RR(REPEATABLE READ)  隔離級(jí)別的實(shí)現(xiàn)就是通過(guò)上面的版本控制來(lái)完成。兩種隔離界別下的核心處理邏輯就是判斷所有版本中哪個(gè)版本是當(dāng)前事務(wù)可見的處理。針對(duì)這個(gè)問(wèn)題InnoDB在設(shè)計(jì)上增加了ReadView的設(shè)計(jì)，ReadView中主要包含當(dāng)前系統(tǒng)中還有哪些活躍的讀寫事務(wù)，把它們的事務(wù)id放到一個(gè)列表中，我們把這個(gè)列表命名為為m_ids。

對(duì)于查詢時(shí)的版本鏈數(shù)據(jù)是否看見的判斷邏輯：

• 如果被訪問(wèn)版本的 trx_id 屬性值小于 m_ids 列表中最小的事務(wù)id，表明生成該版本的事務(wù)在生成 ReadView  前已經(jīng)提交，所以該版本可以被當(dāng)前事務(wù)訪問(wèn)。

• 如果被訪問(wèn)版本的 trx_id 屬性值大于 m_ids 列表中最大的事務(wù)id，表明生成該版本的事務(wù)在生成 ReadView  后才生成，所以該版本不可以被當(dāng)前事務(wù)訪問(wèn)。

• 如果被訪問(wèn)版本的 trx_id 屬性值在 m_ids 列表中最大的事務(wù)id和最小事務(wù)id之間，那就需要判斷一下 trx_id 屬性值是不是在 m_ids  列表中，如果在，說(shuō)明創(chuàng)建 ReadView 時(shí)生成該版本的事務(wù)還是活躍的，該版本不可以被訪問(wèn);如果不在，說(shuō)明創(chuàng)建 ReadView  時(shí)生成該版本的事務(wù)已經(jīng)被提交，該版本可以被訪問(wèn)。

舉個(gè)例子：

READ COMMITTED 隔離級(jí)別下的ReadView

每次讀取數(shù)據(jù)前都生成一個(gè)ReadView (m_ids列表)

時(shí)間	Transaction 777	Transaction 888	Trasaction 999
T1	begin;
T2		begin;	begin；
T3	UPDATE user SET name = 'CR7' WHERE id = 1;
T4		...
T5	UPDATE user SET name = 'Messi' WHERE id = 1;		SELECT * FROM user where id = 1;
T6	commit;
T7		UPDATE user SET name = 'Neymar' WHERE id = 1;
T8			SELECT * FROM user where id = 1;
T9		UPDATE user  SET name = 'Dybala' WHERE id = 1;
T10		commit;
T11			SELECT * FROM user where id = 1;

這里分析下上面的情況下的ReadView

時(shí)間點(diǎn) T5 情況下的 SELECT 語(yǔ)句：

當(dāng)前時(shí)間點(diǎn)的版本鏈：

此時(shí) SELECT 語(yǔ)句執(zhí)行，當(dāng)前數(shù)據(jù)的版本鏈如上，因?yàn)楫?dāng)前的事務(wù)777，和事務(wù)888 都未提交，所以此時(shí)的活躍事務(wù)的ReadView的列表情況  m_ids：[777, 888] ，因此查詢語(yǔ)句會(huì)根據(jù)當(dāng)前版本鏈中小于 m_ids 中的最大的版本數(shù)據(jù)，即查詢到的是 Mbappe。

時(shí)間點(diǎn) T8 情況下的 SELECT 語(yǔ)句：

當(dāng)前時(shí)間的版本鏈情況：

此時(shí) SELECT 語(yǔ)句執(zhí)行，當(dāng)前數(shù)據(jù)的版本鏈如上，因?yàn)楫?dāng)前的事務(wù)777已經(jīng)提交，和事務(wù)888 未提交，所以此時(shí)的活躍事務(wù)的ReadView的列表情況  m_ids：[888] ，因此查詢語(yǔ)句會(huì)根據(jù)當(dāng)前版本鏈中小于 m_ids 中的最大的版本數(shù)據(jù)，即查詢到的是 Messi。

時(shí)間點(diǎn) T11 情況下的 SELECT 語(yǔ)句：

當(dāng)前時(shí)間點(diǎn)的版本鏈信息：

此時(shí) SELECT 語(yǔ)句執(zhí)行，當(dāng)前數(shù)據(jù)的版本鏈如上，因?yàn)楫?dāng)前的事務(wù)777和事務(wù)888 都已經(jīng)提交，所以此時(shí)的活躍事務(wù)的ReadView的列表為空  ，因此查詢語(yǔ)句會(huì)直接查詢當(dāng)前數(shù)據(jù)庫(kù)最新數(shù)據(jù)，即查詢到的是 Dybala。

總結(jié)： 使用READ COMMITTED隔離級(jí)別的事務(wù)在每次查詢開始時(shí)都會(huì)生成一個(gè)獨(dú)立的 ReadView。

REPEATABLE READ 隔離級(jí)別下的ReadView

在事務(wù)開始后第一次讀取數(shù)據(jù)時(shí)生成一個(gè)ReadView(m_ids列表)

時(shí)間	Transaction 777	Transaction 888	Trasaction 999
T1	begin;
T2		begin;	begin；
T3	UPDATE user SET name = 'CR7' WHERE id = 1;
T4		...
T5	UPDATE user SET name = 'Messi' WHERE id = 1;		SELECT * FROM user where id = 1;
T6	commit;
T7		UPDATE user SET name = 'Neymar' WHERE id = 1;
T8			SELECT * FROM user where id = 1;
T9		UPDATE user  SET name = 'Dybala' WHERE id = 1;
T10		commit;
T11			SELECT * FROM user where id = 1;

時(shí)間點(diǎn) T5 情況下的 SELECT 語(yǔ)句：

當(dāng)前版本鏈：

再當(dāng)前執(zhí)行select語(yǔ)句時(shí)生成一個(gè)ReadView，此時(shí) m_ids 內(nèi)容是：[777,888]，所以但前根據(jù)ReadView可見版本查詢到的數(shù)據(jù)為  Mbappe。

時(shí)間點(diǎn) T8 情況下的 SELECT 語(yǔ)句：

當(dāng)前的版本鏈：

此時(shí)在當(dāng)前的 Transaction 999  的事務(wù)里。由于T5的時(shí)間點(diǎn)已經(jīng)生成了ReadView，所以再當(dāng)前的事務(wù)中只會(huì)生成一次ReadView，所以此時(shí)依然沿用T5時(shí)的m_ids：[777,999]，所以此時(shí)查詢數(shù)據(jù)依然是  Mbappe。

時(shí)間點(diǎn) T11 情況下的 SELECT 語(yǔ)句：

當(dāng)前的版本鏈：

此時(shí)情況跟T8完全一樣。由于T5的時(shí)間點(diǎn)已經(jīng)生成了ReadView，所以再當(dāng)前的事務(wù)中只會(huì)生成一次ReadView，所以此時(shí)依然沿用T5時(shí)的m_ids：[777,999]，所以此時(shí)查詢數(shù)據(jù)依然是  Mbappe。

MVCC總結(jié)：

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

在 MySQL 中， READ COMMITTED 和 REPEATABLE READ 隔離級(jí)別的的一個(gè)非常大的區(qū)別就是它們生成 ReadView  的時(shí)機(jī)不同。在 READ COMMITTED 中每次查詢都會(huì)生成一個(gè)實(shí)時(shí)的 ReadView，做到保證每次提交后的數(shù)據(jù)是處于當(dāng)前的可見狀態(tài)。而  REPEATABLE READ 中，在當(dāng)前事務(wù)第一次查詢時(shí)生成當(dāng)前的 ReadView，并且當(dāng)前的 ReadView  會(huì)一直沿用到當(dāng)前事務(wù)提交，以此來(lái)保證可重復(fù)讀(REPEATABLE READ)。

關(guān)于MySQL事務(wù)與MVCC怎么實(shí)現(xiàn)隔離級(jí)別就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺(jué)得文章不錯(cuò)，可以把它分享出去讓更多的人看到。

分享題目：MySQL事務(wù)與MVCC怎么實(shí)現(xiàn)隔離級(jí)別
本文路徑：http://www.rwnh.cn/article38/pgsjpp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站設(shè)計(jì)公司、用戶體驗(yàn)、品牌網(wǎng)站制作、全網(wǎng)營(yíng)銷推廣、App開發(fā)、App設(shè)計(jì)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)