MySQL 多版本併發控制機制（MVCC）原始碼淺析-知識星球

(點選上方藍字，快速關註我們)

來源：無毀的湖光-Al

my.oschina.net/alchemystar/blog/1927425?tdsourcetag=s_pcqq_aiomsg

前言

作為一個資料庫愛好者，自己動手寫過簡單的SQL解析器以及儲存引擎，但感覺還是不夠過癮。<>誠然講的非常透徹，但只能提綱挈領，不能讓你玩轉某個真正的資料庫。感謝cmake,能夠讓我在mac上用xcode去debug MySQL,從而能去領略它的各種實現細節。

筆者一直對資料庫的隔離性很好奇，此篇部落格就是我debug MySQL過程中的偶有所得。

(註:本文的MySQL採用的是MySQL-5.6.35版本)

MVCC(多版本併發控制機制)

隔離性也可以被稱作併發控制、可序列化等。談到併發控制首先想到的就是鎖，MySQL透過使用兩階段鎖的方式實現了更新的可序列化，同時為了加速查詢效能，採用了MVCC(Multi Version Concurrency Control)的機制，使得不用鎖也可以獲取一致性的版本。

Repeatable Read

MySQL的透過MVCC以及(Next-Key Lock)實現了可重覆讀(Repeatable Read),其思想(MVCC)就是記錄資料的版本變遷，透過精巧的選擇不同資料的版本從而能夠對使用者呈現一致的結果。如下圖所示:

上圖中，(A=50|B=50)的初始版本為1。

1.事務t1在select A時候看到的版本為1，即A=50

2.事務t2對A和B的修改將版本升級為2,即A=0,B=100

3.事務t1再此select B的時候看到的版本還是1, 即B=50

這樣就隔離了版本的影響，A+B始終為100。

Read Commit

而如果不透過版本控制機制，而是讀到最近提交的結果的話，則隔離級別是read commit,如下圖所示:

在這種情況下，就需要使用鎖機制(例如select for update)將此A,B記錄鎖住，從而獲得正確的一致結果,如下圖所示：

MVCC的優勢

當我們要對一些資料做一些只讀操作來檢查一致性，例如檢查賬務是否對齊的操作時候，並不希望加上對效能損耗很大的鎖。這時候MVCC的一致性版本就有很大的優勢了。

MVCC(實現機制)

本節就開始談談MVCC的實現機制,註意MVCC僅僅在純select時有效(不包括select for update,lock in share mode等加鎖操作,以及updateinsert等)。

select執行棧

首先我們追蹤一下一條普通的查詢sql在mysql原始碼中的執行過程,sql為(select * from test);

其執行棧為:

由於mysql預設隔離級別是repeatable_read(RR),所以read_record多載為 rr_sequential(當前我們並不關心select透過index掃描出row之後再透過condition過濾的過程)。繼續追蹤:

讓我們看下該函式內部:

bool lock_clust_rec_cons_read_sees(const rec_t* rec /*由innodb掃描出來的一行*/,….){

…

// 從當前掃描的行中獲取其最後修改的版本trx_id(事務id)

trx_id = row_get_rec_trx_id(rec, index, offsets);

// 透過引數(一致性快照檢視和事務id)決定看到的行快照

return(read_view_sees_trx_id(view, trx_id));

}

read_view的建立過程

我們先關註一致性檢視的建立過程,我們先看下read_view結構:

然後透過debug，發現建立read_view結構也是在上述的rr_sequential中操作的，繼續跟蹤呼叫棧:

我們看下row_search_for_mysql裡的一個分支:

row_search_for_mysql:

// 這邊只有select不加鎖樣式的時候才會建立一致性檢視

else if (prebuilt->select_lock_type == LOCK_NONE) { // 建立一致性檢視

trx_assign_read_view(trx);

prebuilt->sql_stat_start = FALSE;

}