前言
其實數據庫章節基本上的知識點我都寫過一遍了，包括這篇事務和MVCC的，但是國慶期間我翻閱資料的時候我發現之前寫的還差點意思，例子舉得也差點意思，那我就根據我自己最新的理解，加上之前的總結相當於重寫了，希望你也有新的收穫。
數據庫事務介紹
事務的四大特性（ACID）
-
原子性(atomicity)： 事務的最小工作單元，要麼全成功，要麼全失敗。
-
一致性(consistency)： 事務開始和結束後，數據庫的完整性不會被破壞。
-
隔離性(isolation)： 不同事務之間互不影響，四種隔離級別爲RU（讀未提交）、RC（讀已提交）、RR（可重複讀）、SERIALIZABLE （串行化）。
-
持久性(durability)： 事務提交後，對數據的修改是永久性的，即使系統故障也不會丟失。
事務的隔離級別
讀未提交（Read UnCommitted/RU）
又稱爲髒讀，一個事務可以讀取到另一個事務未提交的數據。這種隔離級別歲最不安全的一種，因爲未提交的事務是存在回滾的情況。
讀已提交（Read Committed/RC）
又稱爲不可重複讀，一個事務因爲讀取到另一個事務已提交的修改數據，導致在當前事務的不同時間讀取同一條數據獲取的結果不一致。
舉個例子，在下面的例子中就會發現SessionA在一個事務期間兩次查詢的數據不一樣。原因就是在於當前隔離級別爲 RC，SessionA的事務可以讀取到SessionB提交的最新數據。
| 發生時間 | SessionA | SessionB |
|---|---|---|
| 1 | begin; | |
| 2 | select * from user where id=1;(張三) | |
| 3 | update user set name=‘李四’ where id=1;(默認隱式提交事務) | |
| 4 | select * from user where id=1;(李四) | |
| 5 | update user set name=‘王二’ where id=1;(默認隱式提交事務) | |
| 6 | select * from user where id=1;(王二) |
可重複讀（Repeatable Read/RR）
又稱爲幻讀，一個事物讀可以讀取到其他事務提交的數據，但是在RR隔離級別下，當前讀取此條數據只可讀取一次，在當前事務中，不論讀取多少次，數據任然是第一次讀取的值，不會因爲在第一次讀取之後，其他事務再修改提交此數據而產生改變。因此也成爲幻讀，因爲讀出來的數據並不一定就是最新的數據。
舉個例子：在SessionA中第一次讀取數據時，後續其他事務修改提交數據，不會再影響到SessionA讀取的數據值。此爲可重複讀。
| 發生時間 | SessionA | SessionB |
|---|---|---|
| 1 | begin; | |
| 2 | select * from user where id=1;(張三) | |
| 3 | update user set name=‘李四’ where id=1; (默認隱式提交事務) | |
| 4 | select * from user where id=1;(張三) | |
| 5 | update user set name=‘王二’ where id=1;(默認隱式提交事務) | |
| 6 | select * from user where id=1;(張三) |
串行化（Serializable）
所有的數據庫的讀或者寫操作都爲串行執行，當前隔離級別下只支持單個請求同時執行，所有的操作都需要隊列執行。所以種隔離級別下所有的數據是最穩定的，但是性能也是最差的。數據庫的鎖實現就是這種隔離級別的更小粒度版本。
| 發生時間 | 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;(李四) |
事務和MVCC原理
不同事務同時操作同一條數據產生的問題
示例：
| 發生時間 | SessionA | SessionB |
|---|---|---|
| 1 | begin; | |
| 2 | begin; | |
| 3 | 查詢餘額 = 1000元 | |
| 4 | 查詢餘額 = 1000元 | |
| 5 | 存入金額 100元，修改餘額爲 1100元 | |
| 6 | 取出現金100元，此時修改餘額爲900元 | |
| 8 | 提交事務（餘額=1100） | |
| 9 | 提交事務（餘額=900） |
| 發生時間 | SessionA | SessionB |
|---|---|---|
| 1 | begin; | |
| 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 會根據以下兩個條件檢查每行記錄：
-
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 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 語句：
當前時間點的版本鏈：
此時 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 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 語句：
當前版本鏈：
再當前執行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），即同事務內的多次 select 數據是一致的，但這個數據不一定是最新的。