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

自動寫代碼機器人，免費開通

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

數據庫事務

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

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

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

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

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

事務的隔離級別

讀未提交 (Read UnCommitted/RU)

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

讀已提交 (Read Committed/RC)

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

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

發生時間 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)

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

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

發生時間 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)

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

發生時間 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 原理不同事務同時操作同一條數據產生的問題

示例：

發生時間 SessionASessionB1begin; 2 begin;3  查詢余額 = 1000 元 4 查詢余額 = 1000 元  5  存入金額 100 元，修改余額為 1100 元 6 取出現金 100 元，此時修改余額為 900 元  8  提交事務（余額 =1100）9 提交事務（余額 =900）
 

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

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

LBCC 解決數據丟失

LBCC，基于鎖的并發控制，Lock Based Concurrency Control。

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

MVCC 解決數據丟失

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

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

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

InnoDB 的 MVCC 實現邏輯

InnoDB 存儲引擎保存的 MVCC 的數據

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

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

SELECT

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

鴻蒙官方戰略合作共建——HarmonyOS 技術社區

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

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

INSERT

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

DELETE

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

UPDATE

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

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

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

MVCC 在 mysql 中的實現依賴的是 undo log 與 read view。

undo log

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

insert undo log：

insert 操作中產生的 undo log，因為 insert 操作記錄只對當前事務本身課件，對于其他事務此記錄不可見，所以 insert undo log   可以在事務提交后直接刪除而不需要進行 purge 操作。

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

數據庫 Insert 時的數據初始狀態：

update undo log：

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

數據第一次被修改時：

當另一個事務第二次修改當前數據：

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

ReadView

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

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

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

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

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

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

舉個例子：

READ COMMITTED 隔離級別下的 ReadView

每次讀取數據前都生成一個 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 語句執行，當前數據的版本鏈如上，因為當前的事務 777，和事務 888 都未提交，所以此時的活躍事務的 ReadView 的列表情況  m_ids：[777, 888]，因此查詢語句會根據當前版本鏈中小于 m_ids 中的最大的版本數據，即查詢到的是 Mbappe。

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

當前時間的版本鏈情況：

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

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

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

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

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

REPEATABLE READ 隔離級別下的 ReadView

在事務開始后第一次讀取數據時生成一個 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 語句：

當前版本鏈：

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

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

當前的版本鏈：

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

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

當前的版本鏈：

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

MVCC 總結：

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

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

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

向 AI 問一下細節