MySQL事務(wù)和MVCC怎么實(shí)現(xiàn)隔離級(jí)別

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

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

MySQL事務(wù)和MVCC怎么實(shí)現(xiàn)隔離級(jí)別

數(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）

又稱為臟讀，一個(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í)間SessionASessionB
1begin;
2select * from user where id=1;(張三)
3
update user set name='李四' where id=1;(默認(rèn)隱式提交事務(wù))
4select * from user where id=1;(李四)
5
update user set name='王二' where id=1;(默認(rèn)隱式提交事務(wù))
6select * 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í)間SessionASessionB
1begin;
2select * from user where id=1;(張三)
3
update user set name='李四' where id=1;  (默認(rèn)隱式提交事務(wù))
4select * from user where id=1;(張三)
5
update user set name='王二' where id=1;(默認(rèn)隱式提交事務(wù))
6select * 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í)間SessionASessionB
1begin;
2
begin;
3
update user set name='李四' where id=1;
4select * from user where id=1;(等待、wait)
5
commit；
6select * from user where id=1;(李四)

事務(wù)和MVCC原理

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

示例：

發(fā)生時(shí)間SessionASessionB
1begin;
2
begin;
3
查詢余額 = 1000元
4查詢余額 = 1000元
5
存入金額 100元，修改余額為 1100元
6取出現(xiàn)金100元，此時(shí)修改余額為900元
8
提交事務(wù)（余額=1100）
9提交事務(wù)（余額=900）
發(fā)生時(shí)間SessionASessionB
1begin;
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ù)開(kāi)始修改賬戶且事務(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）。每開(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)查詢時(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è)條件的記錄，才能返回作為查詢結(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ù)此記錄不可見(jiàn)，所以 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ù)可見(jiàn)的處理。針對(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ù)是否看見(jiàn)的判斷邏輯：

  • 如果被訪問(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 777Transaction 888Trasaction 999
T1begin;

T2
begin;begin；
T3UPDATE user SET name = 'CR7' WHERE id = 1;

T4
...
T5UPDATE user SET name = 'Messi' WHERE id = 1;
SELECT * FROM user where id = 1;
T6commit;

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ù)在每次查詢開(kāi)始時(shí)都會(huì)生成一個(gè)獨(dú)立的 ReadView。

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

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

時(shí)間Transaction 777Transaction 888Trasaction 999
T1begin;

T2
begin;begin；
T3UPDATE user SET name = 'CR7' WHERE id = 1;

T4
...
T5UPDATE user SET name = 'Messi' WHERE id = 1;
SELECT * FROM user where id = 1;
T6commit;

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可見(jiàn)版本查詢到的數(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。

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

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

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

廣告

聲明：本網(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)

外貿(mào)網(wǎng)站制作