共計 5948 個字符，預計需要花費 15 分鐘才能閱讀完成。

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

數(shù)據(jù)庫事務介紹事務的四大特性（ACID）

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

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

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

持久性(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ā)生時間 SessionASessionB1begin;
2select * from user where id=1;(張三)
3
update user set name= 李四 where id=1;(默認隱式提交事務)4select * from user where id=1;(李四)
5
update user set name= 王二 where id=1;(默認隱式提交事務)6select * 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ā)生時間 SessionASessionB1begin;
2select * from user where id=1;(張三)
3
update user set name= 李四 where id=1;  (默認隱式提交事務)4select * from user where id=1;(張三)
5
update user set name= 王二 where id=1;(默認隱式提交事務)6select * from user where id=1;(張三)

串行化（Serializable）

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

發(fā)生時間 SessionASessionB1begin;
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;(李四)
事務和 MVCC 原理不同事務同時操作同一條數(shù)據(jù)產(chǎn)生的問題

示例：

發(fā)生時間 SessionASessionB1begin;
2
begin;3
查詢余額 = 1000 元 4 查詢余額 = 1000 元
5
存入金額 100 元，修改余額為 1100 元 6 取出現(xiàn)金 100 元，此時修改余額為 900 元
8
提交事務（余額 =1100）9 提交事務（余額 =900）
發(fā)生時間 SessionASessionB1begin;
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ù)以下兩個條件檢查每行記錄：

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

刪除的行要事務 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ā)寫入和持久化。回滾段實際上是一種 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 777Transaction 888Trasaction 999T1begin;

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

時間點 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 777Transaction 888Trasaction 999T1begin;

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;

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

當前版本鏈：

再當前執(zhí)行 select 語句時生成一個 ReadView，此時 m_ids 內容是：[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。

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