MySQL事務和MVCC怎么實現隔離級別

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

數據庫事務介紹

事務的四大特性（ACID）

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

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

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

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

事務的隔離級別

讀未提交（Read UnCommitted/RU）

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

讀已提交（Read Committed/RC）

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

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

可重復讀（Repeatable Read/RR）

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

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

串行化（Serializable）

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

事務和MVCC原理

不同事務同時操作同一條數據產生的問題

示例：

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

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 會根據以下兩個條件檢查每行記錄：

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

2. 刪除的行要事務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列表)

這里分析下上面的情況下的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列表）

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

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