mvcc通過版本隔離和快照機制避免讀寫沖突，提升并發性能。1.事務讀取時基于“read view”查看歷史數據版本，不阻塞寫操作；2.寫入時創建新版本，不影響舊版本讀取；3.使用db_trx_id和db_roll_ptr管理版本可見性；4.后臺purge線程清理不再需要的舊版本數據；5.回滾時利用undo log恢復數據狀態，不影響其他事務。
MVCC（多版本并發控制）機制通過為每個事務提供一個獨立的數據快照，實現了讀操作不阻塞寫操作，寫操作也不阻塞讀操作的“非鎖定讀取”。這意味著，當一個事務在讀取數據時，即使另一個事務正在修改相同的數據，讀取事務也不會被阻塞，它會看到數據的一個歷史版本，從而極大地提升了數據庫的并發性能。
解決方案
MVCC的核心在于它不直接修改原始數據，而是為每次修改創建數據的新版本。想象一下，數據庫里的每一行數據都像有了一個時間軸，每次更新都會在這個時間軸上留下一個新的“足跡”。當一個事務開始時，它會獲得一個“時間戳”或者說一個“視圖”，這個視圖決定了它能看到哪些數據版本。
具體來說，當一個事務需要讀取數據時，它會根據自己的“視圖”去查找那些在它開始之前就已經提交（或對它可見）的數據版本。如果某行數據在它開始之后被修改了，它仍然會讀取那個舊的版本，因為它只關心它“看到”的那個時間點的數據狀態。而當一個事務需要寫入數據時，它不會去鎖住正在被讀取的舊版本，而是創建一個新的數據版本，并將其標記為由當前事務所有。這樣，讀和寫就可以并行不悖地進行，彼此之間互不干擾。這就像你在看一本舊書，而別人在旁邊修改這本書的復印件，你們互不影響。
MVCC如何避免讀寫沖突，提升并發性能？
這其實是MVCC最迷人，也最核心的價值所在。我第一次接觸MVCC時，就覺得這簡直是數據庫并發控制的“圣杯”。傳統的鎖定機制，無論是行鎖還是表鎖，都會讓讀寫操作相互等待，在高并發場景下，這簡直是性能殺手。而MVCC的出現，徹底改變了這種局面。
它避免讀寫沖突的關鍵在于“版本隔離”。當一個事務（比如一個報表查詢）開始讀取數據時，它會得到一個當前數據庫狀態的“快照”。這個快照是基于事務開始時的系統版本號或活躍事務列表來確定的。此后，無論其他事務如何修改甚至刪除數據，這個讀取事務都只會看到它快照里的那個版本。這意味著，讀取操作幾乎不會被寫入操作阻塞，因為它們操作的是不同“時間線”上的數據。
與此同時，寫入操作也不會因為有讀取操作而等待。寫入操作會創建新的數據版本，并更新行記錄的元數據（比如，指向新版本的指針或版本號）。舊版本的數據依然存在，供那些持有舊快照的讀取事務訪問。這種設計極大地減少了鎖的競爭，尤其是在讀多寫少的應用場景中，并發性能的提升是立竿見影的。它讓數據庫在處理大量并發請求時顯得游刃有余，不再是那個動輒“卡殼”的瓶頸。當然，這并不是說完全沒有鎖，寫操作內部，或者為了保證數據一致性，仍然會有鎖，但那是行級別的，且持續時間通常很短，與讀操作的沖突被巧妙地化解了。
MVCC中的版本管理和可見性規則是怎樣的？
要理解MVCC的精髓，就必須深入到它的版本管理和可見性規則。這部分有點像數據庫內部的“時間旅行”機制。在許多MVCC實現中，比如InnoDB，每行數據通常會帶有一些隱藏的列，這些列用于記錄版本信息。最常見的可能是：
- DB_TRX_ID (或類似字段)： 記錄了最后一次修改該行的事務ID。
- DB_ROLL_PTR (或類似字段)： 這是一個回滾指針，指向undo log中該行上一個版本的記錄。通過這個指針，可以回溯到該行的歷史版本。
當一個事務開始時，它會獲得一個“Read View”（讀取視圖）。這個視圖包含了當前所有活躍事務的ID列表，以及一個最小和最大的事務ID范圍。這個“Read View”就是決定哪些數據版本對當前事務可見的核心規則。
具體可見性判斷通常是這樣的：
- 對于一行數據的一個版本：
- 如果該版本的DB_TRX_ID小于“Read View”中的最小活躍事務ID，那么這個版本是在當前事務開始之前就已經提交的，它是可見的。
- 如果該版本的DB_TRX_ID大于“Read View”中的最大活躍事務ID，那么這個版本是在當前事務開始之后才創建的，它是不可見的。
- 如果該版本的DB_TRX_ID在最小和最大活躍事務ID之間：
- 如果這個DB_TRX_ID在“Read View”的活躍事務列表中，說明創建這個版本的事務還在進行中（未提交），那么這個版本是不可見的。需要沿著DB_ROLL_PTR回溯到更舊的版本，直到找到一個可見的版本。
- 如果這個DB_TRX_ID不在活躍事務列表中，說明創建這個版本的事務已經提交了，那么這個版本是可見的。
這種機制確保了每個事務都看到了一個邏輯上一致的數據狀態，即使底層數據正在被并發修改。這種精妙的設計，使得“非鎖定讀取”成為可能，也讓數據庫在并發處理能力上邁上了一個新臺階。
MVCC如何處理事務回滾和舊版本清理？
MVCC雖然帶來了巨大的便利，但它也引入了新的管理挑戰，尤其是事務回滾和舊版本數據的清理。這就像你不斷地制造數據副本，總得有個機制來處理那些不再需要的“舊照片”。
事務回滾： 當一個事務需要回滾時，MVCC的處理相對直接。因為寫入操作是創建新版本而不是直接修改舊版本，回滾只需要利用DB_ROLL_PTR指向的undo log信息，將那些未提交的新版本標記為無效，或者通過undo log將數據狀態恢復到事務開始前的樣子。那些被回滾的未提交的新版本，對于其他事務來說，本來就是不可見的，所以回滾操作不會影響到其他正在運行的事務。這比傳統鎖定機制的回滾要優雅得多，因為它避免了復雜的鎖釋放和數據恢復過程。
舊版本清理（Purge）： 這是MVCC實現中一個非常關鍵且復雜的部分，被稱為“垃圾回收”或“Purge”。隨著數據不斷更新，數據庫中會積累大量的舊版本數據。這些舊版本數據不能立即刪除，因為可能還有活躍的事務正在使用它們（它們的“Read View”可能需要看到這些舊版本）。
所以，數據庫通常會有一個后臺線程（例如InnoDB的Purge線程），它會定期掃描那些不再被任何活躍事務引用的舊版本數據，并將其從存儲中物理刪除。這個過程需要非常小心，因為它必須確保沒有正在運行的事務還需要訪問這些舊版本。判斷一個舊版本是否可以被清理的依據，就是看當前所有活躍事務的“Read View”中，是否都不再需要訪問這個版本。如果所有活躍事務的最小可見事務ID都大于這個舊版本的創建事務ID，那么這個舊版本就可以安全地被清理了。
如果舊版本數據積累過多，Purge線程可能會跟不上，這可能導致undo log文件膨脹，甚至影響數據庫的性能。因此，一個高效的Purge機制是MVCC數據庫健康運行的重要保障。它就像一個默默無聞的清潔工，確保數據庫的“時間機器”不會因為歷史版本過多而變得臃腫不堪。
