這篇文章主要講解了“MySQL事務(wù)和MVCC怎么實現(xiàn)隔離級別”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“MySQL事務(wù)和MVCC怎么實現(xiàn)隔離級別”吧！

站在用戶的角度思考問題，與客戶深入溝通，找到察哈爾右翼后網(wǎng)站設(shè)計與察哈爾右翼后網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗，讓設(shè)計與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個性化、用戶體驗好的作品，建站類型包括：成都網(wǎng)站制作、成都做網(wǎng)站、外貿(mào)營銷網(wǎng)站建設(shè)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣、域名申請、網(wǎng)絡(luò)空間、企業(yè)郵箱。業(yè)務(wù)覆蓋察哈爾右翼后地區(qū)。

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

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

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

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

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

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

事務(wù)的隔離級別

讀未提交（Read UnCommitted/RU）

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

讀已提交（Read Committed/RC）

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

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

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

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

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

發(fā)生時間	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ù)庫的讀或者寫操作都為串行執(zhí)行，當(dāng)前隔離級別下只支持單個請求同時執(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;(李四)

事務(wù)和MVCC原理

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

示例：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SELECT

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

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

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

INSERT

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

DELETE

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

UPDATE

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

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

MVCC只在REPEATABLE READ和READ COMMITIED兩個隔離級別下工作。其他兩個隔離級別都和 MVCC不兼容 ，因為READ UNCOMMITIED總是讀取最新的數(shù)據(jù)行，而不是符合當(dāng)前事務(wù)版本的數(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操作記錄只對當(dāng)前事務(wù)本身課件，對于其他事務(wù)此記錄不可見，所以 insert undo log 可以在事務(wù)提交后直接刪除而不需要進行purge操作。

purge的主要任務(wù)是將數(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 不能在事務(wù)提交時就進行刪除，而是將事務(wù)提交時放到入 history list 上，等待 purge 線程進行最后的刪除操作。

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

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

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

ReadView

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

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

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

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

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

• 如果被訪問版本的 trx_id 屬性值在 m_ids 列表中最大的事務(wù)id和最小事務(wù)id之間，那就需要判斷一下 trx_id 屬性值是不是在 m_ids 列表中，如果在，說明創(chuàng)建 ReadView 時生成該版本的事務(wù)還是活躍的，該版本不可以被訪問；如果不在，說明創(chuàng)建 ReadView 時生成該版本的事務(wù)已經(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 語句：

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

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

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

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

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

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

當(dāng)前時間點的版本鏈信息：

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

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

REPEATABLE READ 隔離級別下的ReadView

在事務(wù)開始后第一次讀取數(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 語句：

當(dāng)前版本鏈：

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

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

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

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

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

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

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

感謝各位的閱讀，以上就是“MySQL事務(wù)和MVCC怎么實現(xiàn)隔離級別”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對MySQL事務(wù)和MVCC怎么實現(xiàn)隔離級別這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！

名稱欄目：MySQL事務(wù)和MVCC怎么實現(xiàn)隔離級別
當(dāng)前地址：http://aaarwkj.com/article12/gjggdc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供做網(wǎng)站、微信小程序、自適應(yīng)網(wǎng)站、網(wǎng)站營銷、網(wǎng)站導(dǎo)航、云服務(wù)器

廣告

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