一文帶你搞懂MySQL的MVCC機制
MVCC，英文全稱Multiversion Concurrency Control，多版本并發(fā)控制。簡單理解，就是相當于給我們的MySQL數(shù)據庫拍個“快照”，定格某個時刻數(shù)據庫的狀態(tài)。
那你可能問為什么要拍個“快照”，也就是MVCC機制？
還記得事務的一大特性就是隔離性，一共有4個隔離級別，讀未提交，讀已提交，可重復讀，串行化。
以MySQL InnoDB 引擎的默認隔離級別可重復讀為例，可重復讀指一個事務執(zhí)行過程中看到的數(shù)據，一直跟這個事務啟動時看到的數(shù)據是一致的。
為了保證事務啟動到結束整個生命周期看到的數(shù)據是一致的, 一般有兩種方案：
MySQL對數(shù)據“讀-寫”的時候，加鎖，其他事務寫這條數(shù)據時加上鎖，其他事務讀取的時候阻塞。MySQL可以對事務啟動的時候，對數(shù)據庫拍個“快照”，那么事務運行過程中讀取都從這個快照讀取，不也是保證數(shù)據一致么。第一種方案存在明顯的問題，加鎖會引發(fā)阻塞，從而降低數(shù)據庫性能。而MySQL設計者們采用第二種，也就是大名鼎鼎的MVCC，它不僅能夠解決不可重復讀，還一定程度解決幻讀的問題，因為你整個數(shù)據庫快照都有了，你就知道那個時刻的數(shù)據了。
雖然說SQL標準定義中可重復讀隔離級別下會存在幻讀的現(xiàn)象，但是不同的數(shù)據庫廠商可以基于SQL標準下有不同的實現(xiàn)，那么不同隔離級別下發(fā)生的現(xiàn)象也會有出入，就拿MySQL的可重復讀隔離級別就可以一定程度保證幻讀。
小結一下：
MVCC在MySQL InnoDB中的實現(xiàn)主要是為了提高數(shù)據庫并發(fā)性能，用更好的方式去處理讀-寫沖突 ，做到即使有讀寫沖突時，也能做到不加鎖 ， 非阻塞并發(fā)讀，而這個讀指的就是快照讀 , 而非當前讀。
什么是快照讀和當前讀？前面提到了快照讀和當前讀，這又有什么不一樣呢，什么樣的sql語句算是快照讀，什么樣的又算是當前讀呢？
快照讀快照讀又叫普通讀，也就是利用MVCC機制讀取快照中的數(shù)據。不加鎖的簡單的SELECT 都屬于快照讀，比如這樣：
SELECT * FROM user WHERE ...快照讀是基于MVCC實現(xiàn)的，提高了并發(fā)的性能，降低開銷大部分業(yè)務代碼中的讀取都屬于快照讀當前讀當前讀讀取的是記錄的最新版本，讀取時會對讀取的記錄進行加鎖, 其他事務就有可能阻塞。加鎖的 SELECT，或者對數(shù)據進行增刪改都會進行當前讀。比如：
SELECT * FROM user LOCK IN SHARE MODE; # 共享鎖SELECT * FROM user FOR UPDATE; # 排他鎖INSERT INTO user values ... # 排他鎖DELETE FROM user WHERE ... # 排他鎖UPDATE user SET ... # 排他鎖update、delete、insert語句雖然沒有select, 但是它們也會先進行讀取，而且只能讀取最新版本。MVCC機制是咋工作的呢？前面打個比方說MVCC機制相當于是基于整個數(shù)據庫“拍了個快照”，這時，你會說這看上去不太現(xiàn)實啊。如果一個庫有 100G，那么我啟動一個事務，MySQL 就要保存 100G 的數(shù)據出來，這個過程得多慢啊，而且也很占用空間啊，根本就不能支持幾個事務啊。別急，我們現(xiàn)在來講解下MVCC機制是如何工作的。
數(shù)據的多個版本首先MySQL innoDB存儲引擎需要支持一條數(shù)據可以保留多個歷史版本。怎么保留呢？還記得事務日志undo log嗎？
對于使用 InnoDB 存儲引擎的數(shù)據庫表，它的聚簇索引記錄中都包含下面兩個隱藏列：
trx_id，當一個事務對某條聚簇索引記錄進行改動時，就會把該事務的事務 id 記錄在 trx_id 隱藏列里；roll_pointer，每次對某條聚簇索引記錄進行改動時，都會把舊版本的記錄寫入到 undo 日志中，然后這個隱藏列是個指針，指向每一個舊版本記錄，于是就可以通過它找到修改前的記錄。InnoDB 里面每個事務有一個唯一的事務 ID，叫作 transaction id。它是在事務開始的時候向 InnoDB 的事務系統(tǒng)申請的，是按申請順序嚴格遞增的。
如上圖所示，針對id=1的這條數(shù)據，都會將舊值放到一條undo日志中，就算是該記錄的一個舊版本，隨著更新次數(shù)的增多，所有的版本都會被 roll_pointer 屬性連接成一個鏈表，我們把這個鏈表稱之為版本鏈，根據版本鏈就可以找到這條數(shù)據歷史的版本。
一致性視圖ReadView利用undo log日志我們已經保留下了數(shù)據的各個版本，那么現(xiàn)在關鍵的問題是要讀取哪個版本的數(shù)據呢？
這時就需要用到ReadView了，ReadView就是事務在使用MVCC機制進行快照讀操作時產生的一致性視圖, 比如針對可重復讀隔離級別，是在事務啟動的時候，創(chuàng)建一個ReadView, 那ReadView種都有哪些關鍵信息呢？
trx_ids: 指的是在創(chuàng)建 ReadView 時，當前數(shù)據庫中「活躍事務」的事務 id 列表，注意是一個列表， “活躍事務”指的就是，啟動了但還沒提交的事務。min_trx_id: 指的是在創(chuàng)建 ReadView 時，當前數(shù)據庫中「活躍事務」中事務 id 最小的事務，也就是 m_ids 的最小值。max_trx_id：這個并不是 m_ids 的最大值，而是創(chuàng)建 ReadView 時當前數(shù)據庫中應該給下一個事務的 id 值，也就是全局事務中最大的事務 id 值 + 1；creator_trx_id ：指的是創(chuàng)建該 ReadView 的事務的事務 id, 只有在對表中的記錄做改動時（執(zhí)行INSERT、DELETE、UPDATE這些語句時）才會為 事務分配事務id，否則在一個只讀事務中的事務id值都默認為0。
對于當前事務的啟動瞬間來說，讀取的一個數(shù)據版本的trx_id，有以下幾種可能：
如果被訪問版本的trx_id屬性值與ReadView中的 creator_trx_id 值相同，意味著當前事務在訪問它自己修改過的記錄，所以該版本可以被當前事務訪問。如果落在綠色部分，表示這個版本是已提交的事務或者是當前事務自己生成的，這個數(shù)據是可見的；如果落在紅色部分，表示這個版本是由將來啟動的事務生成的，是肯定不可見的；如果落在黃色部分，那就包括兩種情況若 數(shù)據的trx_id在trx_ids數(shù)組中，表示這個版本是由還沒提交的事務生成的，不可見, 去讀取這條數(shù)據的歷史版本，這條數(shù)據的歷史版本中都包含了事務id信息，去查找第一個不在活躍事務數(shù)組的版本記錄。若 數(shù)據的trx_id不在trx_ids數(shù)組中，表示這個版本是已經提交了的事務生成的，可見。這種通過版本鏈 + 一致性視圖 來控制并發(fā)事務訪問同一個記錄時的行為就叫 MVCC（多版本并發(fā)控制），現(xiàn)在你明白MySQL如何實現(xiàn)了“秒級創(chuàng)建快照”的能力了吧。
還是不懂？舉例說明如果你對MVCC機制的整個流程還是比較模糊，我們現(xiàn)在舉例來說明下。
比如student表中有一個事務id為8的插入記錄：
insert into student(id, name, class) values(1, '張三', '一班')我們現(xiàn)在在MySQL的讀已提交和可重復讀隔離級別下，MVCC機制的整個工作流程。
MySQL中的讀未提交和序列化并不需要MVCC機制，讀未提交，直接讀取別人未提交的數(shù)據，而序列化全程用加鎖的方式，也用不上MVCC, 大家體會下。
可重復讀隔離級別下可重復讀REPEATABLE READ 隔離級別的事務來說，只會在第一次執(zhí)行查詢語句時生成一個 ReadView ，之后的查詢就不會重復生成了。
begin/start transaction 命令并不是一個事務的起點，在執(zhí)行到它們之后的第一個操作 InnoDB 表的語句，事務才真正啟動。如果你想要馬上啟動一個事務，可以使用 start transaction with consistent snapshot 這個命令。
事務10事務20事務30beginUPDATE student SET name="李四" WHERE id=1;UPDATE student SET name="王五" WHERE id=1;begin更新了一些其他表的數(shù)據beginSELECT * FROM
事務10和20均未提交，現(xiàn)在事務30執(zhí)行select, 那么得到的結果是什么呢？
在執(zhí)行select語句時會先生成一個ReadView，ReadView的trx_ids列表的內容就是[10, 20]，min_trx_id為10，max_trx_id為21，creator_trx_id為0。然后從版本鏈中挑選可見的記錄，從圖中看出，最新版本的列name的內容是'王五'，該版本的trx_id值為10，在trx_ids列表內，所以不符合可見性要求，根據roll_pointer跳到下一個版本。下一個版本的列name的內容是'李四'，該版本的trx_id值也為10，也在trx_ids列表內，所以也不符合要求，繼續(xù)跳到下一個版本。下一個版本的列name的內容是'張三'，該版本的trx_id值為8，小于ReadView中的min_trx_id值10，說明已經提交了，那么最終返回'張三'。讀已提交隔離級別下讀已提交READ COMMITTED是每次讀取數(shù)據前都生成一個ReadView。基本的規(guī)則和流程與可重復讀隔離級別一致，這里不做重復贅敘。
總結本問重點介紹了MVCC機制，以及 MVCC 在 READ COMMITTD、 REPEATABLE READ 這兩種隔離級別的事務在執(zhí)行快照讀操作時訪問記錄的版本鏈的過程。這樣使不同事務的 讀-寫 、 寫-讀 操作并發(fā)執(zhí)行，從而提升系統(tǒng)性能。
READ COMMITTD 在每一次進行普通SELECT操作前都會生成一個ReadViewREPEATABLE READ 只在第一次進行普通SELECT操作前生成一個ReadView，之后的查詢操作都重復使用這個ReadView就好了。以上就是一文帶你搞懂MySQL的MVCC機制的詳細內容，更多關于MySQL MVCC機制的資料請關注好吧啦網其它相關文章！
相關文章：
網公網安備