掃二維碼與項目經理溝通
我們在微信上24小時期待你的聲音
解答本文疑問/技術咨詢/運營咨詢/技術建議/互聯(lián)網(wǎng)交流
MVCC 和間隙鎖是兩種完全不同的機制,但它們的目的都是相同的,都是用來保證數(shù)據(jù)庫并發(fā)訪問的,我們先來看二者的定義。

MVCC 是多版本并發(fā)控制(Multi-Version Concurrency Control)的縮寫,是一種并發(fā)控制的方法。
在 MVCC 中,每個讀操作會看到一個固定版本的數(shù)據(jù)庫記錄,即使在并發(fā)環(huán)境中,也不會出現(xiàn)讀取到了其他事務還未提交的數(shù)據(jù)的情況。
MVCC 通過保存數(shù)據(jù)在某個時間點的快照來實現(xiàn)這一點。在讀取數(shù)據(jù)時,只會讀取在該時間點之前提交的數(shù)據(jù)。在寫入數(shù)據(jù)時,會為每個寫入操作創(chuàng)建一個新版本的數(shù)據(jù),而不是直接覆蓋原有的數(shù)據(jù)。這樣,讀操作就可以讀取舊版本的數(shù)據(jù),而寫操作則可以寫入新版本的數(shù)據(jù),從而實現(xiàn)了并發(fā)控制。
在 MySQL 中,InnoDB 存儲引擎就是使用 MVCC 來實現(xiàn)并發(fā)控制的。
間隙鎖是一種鎖定索引范圍而非實際數(shù)據(jù)的鎖,它可以鎖定一個范圍,防止其他事務在這個范圍內插入數(shù)據(jù),從而保證了范圍內的數(shù)據(jù)的唯一性。在 MySQL 中,InnoDB 存儲引擎支持間隙鎖。當使用 SELECT ... FOR UPDATE 或 SELECT ... LOCK IN SHARE MODE 語句時,InnoDB 存儲引擎會自動使用間隙鎖來鎖定索引范圍。
如果一個事務在一個間隙上持有了鎖,那么其他事務就不能在這個間隙上插入數(shù)據(jù),但是可以在這個間隙之前或之后的位置插入數(shù)據(jù)。
既然已經有鎖可以防止并發(fā)訪問了,那為什么還需要 MVCC 呢?MVCC 的誕生主要是出于性能的考慮,因為 MVCC 中沒有用到鎖,它是通過多版本并發(fā)控制的手段來實現(xiàn)數(shù)據(jù)庫并發(fā)訪問的,這樣相比于加鎖性能就會好很多。
MVCC 竟然這么強,那它是怎么實現(xiàn)的呢?簡單來說 MVCC 是通過以下 3 大組件實現(xiàn)的:
它的實現(xiàn)原理簡單來說,是通過 SQL 中隱藏的字段事務 ID(自己的版本號)和 Read View 中的屬性版本號進行對比,對比之后決定使用 Read View 中的快照或 undo log 中的歷史數(shù)據(jù)(對比的規(guī)則是 MVCC 機制的規(guī)定,本文不展開討論),最后再將符合的數(shù)據(jù)返回。
幻讀是指在一個事務中,第一次查詢某個范圍的數(shù)據(jù)時,發(fā)現(xiàn)有一些數(shù)據(jù)符合條件,但是當再次查詢同樣的范圍時,卻發(fā)現(xiàn)多了一些或者少了一些數(shù)據(jù)。這種情況就被稱為幻讀。幻讀是由于并發(fā)事務中的數(shù)據(jù)修改操作導致的,比如在一個事務中,另一個事務插入了一條符合條件的數(shù)據(jù),導致第二次查詢時多了一條數(shù)據(jù)。
MVCC 機制可以解決部分幻讀問題,MVCC 是通過保存數(shù)據(jù)在某個時間點的快照來實現(xiàn)來解決(部分)幻讀問題的,在讀取數(shù)據(jù)時,MVCC 會根據(jù)快照來確定可見的數(shù)據(jù)版本。這樣,即使其他事務在讀取數(shù)據(jù)時進行了修改,也不會影響當前事務的讀取結果。
因此,MVCC 可以有效地解決這部分幻讀問題。但需要注意的是,MVCC 只能解決讀取數(shù)據(jù)時的幻讀問題,對于寫入數(shù)據(jù)時的幻讀問題,還需要配合鎖機制或使用更高的事務隔離級別(串行化)來解決。
也就是說,想要徹底解決 MySQL InnoDB 中 RR(REPEATABLE READ,可重復讀)事務隔離級別的幻讀問題,需要使用 MVCC + 鎖機制共同來實現(xiàn)。
在 MySQL InnoDB 中的鎖機制不止有間隙鎖,還有行鎖和臨建鎖等。
行鎖、間隙鎖和臨建鎖都是 MySQL 中的鎖機制,它們的區(qū)別如下:
MVCC 和鎖機制解決了 MySQL InnoDB 中 RR 事務隔離級別的幻讀問題,而 MySQL 中的鎖類型又有很多種,如行鎖、間隙鎖、臨建鎖等。

我們在微信上24小時期待你的聲音
解答本文疑問/技術咨詢/運營咨詢/技術建議/互聯(lián)網(wǎng)交流