關于MVCC，你知道多少？
MVCC，即多版本并發控制（Multiversion Concurrency Control），類似于數據庫鎖，是一種優雅的并發控制方案。
我們了解，在數據庫環境中，數據操作主要包括讀取和寫入兩種操作，在并發情境下，可能出現以下三種情況：
- 讀-讀并發
- 讀-寫并發
- 寫-寫并發
眾所周知，在讀取操作時沒有寫入操作的情況下，并發讀取不會引發問題；而寫入操作并發時，常常會通過加鎖的方式來處理。而針對讀取-寫入并發的場景，則可通過MVCC機制來解決。
快照讀和當前讀
要深入了解MVCC機制，其中最關鍵的一個概念就是快照讀。
所謂快照讀，即讀取快照數據，即在生成快照時刻的數據。比如我們常用的普通SELECT語句在無鎖情況下就屬于快照讀。例如：
SELECT * FROM xx_table WHERE ...與快照讀相對應的另一個概念是當前讀，當前讀即獲取最新的數據。因此，加鎖的SELECT操作或進行數據的增刪改都屬于當前讀。例如：
SELECT * FROM xx_table LOCK IN SHARE MODE;
SELECT * FROM xx_table FOR UPDATE;
INSERT INTO xx_table ...
DELETE FROM xx_table ...
UPDATE xx_table ...可以理解為：快照讀是MVCC實現的基礎，而當前讀則是悲觀鎖實現的基礎。
快照讀所讀取的快照數據來自于何處？換言之，這些快照數據存儲在何處？
UndoLog
undo log是 MySQL 中一種重要的事務日志之一。顧名思義，undo log 是用于回滾操作的日志。在事務提交之前，MySQL會將更新前的數據記錄到 undo log 日志文件中。當需要回滾事務或者發生數據庫崩潰時，可以通過 undo log 進行數據回退。
在這個過程中提到的 "更新前的數據" 存儲在undo log中，即我們之前提及的快照。因此，這正是許多人認為 Undo Log 是實現 MVCC 的重要工具的原因之一。
在同一時刻，一條記錄可能會被多個事務操作。因此，undo log 可能會包含一條記錄的多個快照。當需要進行快照讀取時，就要考慮應該讀取哪個快照。這時候就需要利用其他相關信息來做出決定。
行記錄的隱式字段
實際上，在數據庫的每一行記錄中，除了保存我們自定義的字段之外，還包含一些重要的隱式字段：
- db_row_id：隱式主鍵。如果表沒有創建主鍵，將使用該字段創建聚簇索引。
- db_trx_id：最后一次修改該記錄的事務ID。
- db_roll_ptr：回滾指針，指向記錄的上一個版本，在本質上指向Undo Log中的前一個版本的快照地址。
由于每次記錄更改之前都會先將一個快照存儲到undo log中，這些隱式字段也會與記錄一起保存在undo log中。因此，每個快照中都包含一個db_trx_id字段，表示最后一次修改該記錄的事務ID，以及一個db_roll_ptr字段，指向前一個快照的地址。（db_trx_id和db_roll_ptr是重點，將在后續中用到）
因此，這樣就形成了一個快照鏈表：
有了undo log，又有了幾個隱式字段，我們好像還是不知道具體應該讀取哪個快照，那怎么辦呢？
Read View
此時，Read View 登場，它的主要作用是解決可見性問題，即確定當前事務應該查看哪個快照，而不應查看哪個快照。
在 Read View 中具有幾個重要屬性：
- trx_ids：系統當前未提交的事務ID列表。
- low_limit_id：應分配給下一個事務的ID值。
- up_limit_id：未提交事務中最小的事務ID。
- creator_trx_id：創建該 Read View 的事務ID。
每次啟動一個事務，都會獲得一個遞增的事務ID。通過ID的大小，我們可以確定事務的時間順序。
其實原則比較簡單，那就是事務ID大的事務應該能看到事務ID小的事務的變更結果，反之則不能！舉個例子：
假設當前存在一個事務3想要進行快照讀取某條記錄，它會首先創建一個Read View，并記錄所有當前未提交事務的信息。例如，up_limit_id = 2，low_limit_id = 5，trx_ids= [2,4,5]，creator_trx_id= 3
前文提到，每條記錄都包含一個隱式字段db_trx_id，記錄對該記錄進行最新修改的事務ID，例如db_trx_id = 3；
接下來，數據庫將檢查此記錄的db_trx_id與Read View進行可見性比較。
- 若db_trx_id < up_limit_id，則意味著在Read View中所有未提交事務創建之前，事務ID為3的操作已經提交，并在此期間沒有新的提交。因此，對當前事務而言，此記錄應該是可見的。
- 若db_trx_id > low_limit_id，則表示事務ID為3的操作是在Read View中所有未提交事務創建之后才提交的，也就是在當前事務開啟之后，有其他事務修改了數據并提交。因此，這條記錄對當前事務來說是不可見的。（不可見時的處理將在后文討論）
另一種情況是，up_limit_id < db_trx_id < low_limit_id。在此情況下，將db_trx_id與Read View中的trx_ids逐一比較。
- 若db_trx_id在trx_ids列表中，表示在當前事務開啟時，某些未提交事務對數據進行了更改并提交，因此，對當前事務來說，此記錄應該是不可見的。
- 若db_trx_id不在trx_ids列表中，表示在當前事務開啟之前，其他事務對數據進行了修改并提交，所以對當前事務來說，該記錄是可見的。
因此，在讀取記錄時，經過上述判斷，若記錄對當前事務可見，則直接返回。若不可見，則需要利用undo log。
當數據的事務ID與Read View規則不符時，需要從undo log中獲取數據的歷史快照，然后使用數據快照的事務ID與Read View進行可見性比較。如果找到一條快照，則返回數據；否則，返回空。
因此，在InnoDB中，MVCC機制通過Read View和Undo Log相結合來實現。Undo Log保存了歷史快照，而Read View則確定了哪一個具體的快照對當前操作是可見的。
MVCC和可重復讀
根據不同的事務隔離級別，在InnoDB中，獲取Read View的時機有所不同。在可重復讀隔離級別下，每次查詢都會重新獲取一次Read View，而在讀已提交隔離級別下，只有在事務的第一次查詢時獲取一次Read View。
因此，在可重復讀隔離級別下，由于MVCC機制的存在，能夠有效解決不可重復讀的問題。因為在可重復讀隔離級別中，只在第一次查詢時獲取一次Read View，從而天然消除了可能導致重讀問題的可能性。
