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

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

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

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

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

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

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

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

事務的隔離級別

讀未提交(Read UnCommitted/RU)

又稱為臟讀，一個事務可以讀取到另一個事務未提交的數(shù)據(jù)。這種隔離級別歲最不安全的一種，因為未提交的事務是存在回滾的情況。

讀已提交(Read Committed/RC)

又稱為不可重復讀，一個事務因為讀取到另一個事務已提交的修改數(shù)據(jù)，導致在當前事務的不同時間讀取同一條數(shù)據(jù)獲取的結果不一致。

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

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

可重復讀(Repeatable Read/RR)

又稱為幻讀，一個事物讀可以讀取到其他事務提交的數(shù)據(jù)，但是在RR隔離級別下，當前讀取此條數(shù)據(jù)只可讀取一次，在當前事務中，不論讀取多少次，數(shù)據(jù)任然是第一次讀取的值，不會因為在第一次讀取之后，其他事務再修改提交此數(shù)據(jù)而產(chǎn)生改變。因此也成為幻讀，因為讀出來的數(shù)據(jù)并不一定就是最新的數(shù)據(jù)。

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

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

串行化(Serializable)

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

發(fā)生時間	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;(李四)

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

示例：

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

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

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

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

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

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

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

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

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

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

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

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

InnoDB的MVCC是通過在每行記錄后面保存兩個隱藏的列來實現(xiàn)的。一個保存了行的事務ID(DB_TRX_ID)，一個保存了行的回滾指針(DB_ROLL_PT)。每開始一個新的事務，都會自動遞增產(chǎn)  生一個新的事務id。事務開始時刻的會把事務id放到當前事務影響的行事務id中，當查詢時需要用當前事務id和每行記錄的事務id進行比較。

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

SELECT

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

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

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

3. 刪除的行要事務ID判斷，讀取到事務開始之前狀態(tài)的版本，只有符合上述兩個條件的記錄，才能返回作為查詢結果。

INSERT

InnoDB為新插入的每一行保存當前事務編號作為行版本號。

DELETE

InnoDB為刪除的每一行保存當前事務編號作為行刪除標識。

UPDATE

InnoDB為插入一行新記錄，保存當前事務編號作為行版本號，同時保存當前事務編號到原來的行作為行刪除標識。

保存這兩個額外事務編號，使大多數(shù)讀操作都可以不用加鎖。這樣設計使得讀數(shù)據(jù)操作很簡單，性能很好，并且也能保證只會讀取到符合標準的行。不足之處是每行記錄都需要額外的存儲空間，需要做更多的行檢查工作，以及一些額外的維護工作。

MVCC只在REPEATABLE READ和READ COMMITIED兩個隔離級別下工作。其他兩個隔離級別都和 MVCC不兼容 ，因為READ  UNCOMMITIED總是讀取最新的數(shù)據(jù)行，而不是符合當前事務版本的數(shù)據(jù)行。而SERIALIZABLE則會對所有讀取的行都加鎖。

MVCC 在mysql 中的實現(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，因為insert操作記錄只對當前事務本身課件，對于其他事務此記錄不可見，所以 insert undo log  可以在事務提交后直接刪除而不需要進行purge操作。

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

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

• update undo log：

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

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

當另一個事務第二次修改當前數(shù)據(jù)：

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

ReadView

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

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

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

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

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

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

舉個例子：

READ COMMITTED 隔離級別下的ReadView

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

時間	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

時間點 T5 情況下的 SELECT 語句：

當前時間點的版本鏈：

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

時間點 T8 情況下的 SELECT 語句：

當前時間的版本鏈情況：

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

時間點 T11 情況下的 SELECT 語句：

當前時間點的版本鏈信息：

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

總結： 使用READ COMMITTED隔離級別的事務在每次查詢開始時都會生成一個獨立的 ReadView。

REPEATABLE READ 隔離級別下的ReadView

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

時間	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;

時間點 T5 情況下的 SELECT 語句：

當前版本鏈：

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

時間點 T8 情況下的 SELECT 語句：

當前的版本鏈：

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

時間點 T11 情況下的 SELECT 語句：

當前的版本鏈：

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

MVCC總結：

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

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

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

分享題目：MySQL事務與MVCC怎么實現(xiàn)隔離級別
本文路徑：http://jinyejixie.com/article38/pgsjpp.html

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

廣告

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