MySQL MVCC

時間 2019-11-16

標籤 mysql mvcc 欄目 MySQL 简体版

原文原文鏈接

MySQL事務隔離級別的實現原理

回顧

在MySQL的衆多存儲引擎中，只有InnoDB支持事務，全部這裏說的事務隔離級別指的是InnoDB下的事務隔離級別。html

讀未提交：一個事務能夠讀取到另外一個事務未提交的修改。這會帶來髒讀、幻讀、不可重複讀問題。（基本沒用）mysql

讀已提交：一個事務只能讀取另外一個事務已經提交的修改。其避免了髒讀，但仍然存在不可重複讀和幻讀問題。sql

可重複讀：同一個事務中屢次讀取相同的數據返回的結果是同樣的。其避免了髒讀和不可重複讀問題，但幻讀依然存在。數據庫

串行化：事務串行執行。避免了以上全部問題。併發

以上是SQL-92標準中定義的四種隔離級別。在MySQL中，默認的隔離級別是REPEATABLE-READ（可重複讀），而且解決了幻讀問題。簡單的來講，mysql的默認隔離級別解決了髒讀、幻讀、不可重複讀問題。post

不可重複讀重點在於update和delete，而幻讀的重點在於insert。url

在這裏，咱們只討論可重複讀。htm

知識儲備

MVCC

譯註：blog

　　MVCC的全稱是「多版本併發控制」。這項技術使得InnoDB的事務隔離級別下執行一致性讀操做有了保證，換言之，就是爲了查詢一些正在被另外一個事務更新的行，而且能夠看到它們被更新以前的值。這是一個能夠用來加強併發性的強大的技術，由於這樣的一來的話查詢就不用等待另外一個事務釋放鎖。這項技術在數據庫領域並非廣泛使用的。一些其它的數據庫產品，以及mysql其它的存儲引擎並不支持它。索引

說明

網上看到大量的文章講到MVCC都是說給沒一行增長兩個隱藏的字段分別表示行的建立時間以及過時時間，它們存儲的並非時間，而是事務版本號。

事實上，這種說法並不許確，嚴格的來說，InnoDB會給數據庫中的每一行增長三個字段，它們分別是DB_TRX_ID、DB_ROLL_PTR、DB_ROW_ID（若是表設置了主鍵或者惟一索引，row_id則不會分配）。

可是，爲了理解的方便，咱們能夠這樣去理解，索引接下來的講解中也仍是用這兩個字段的方式去理解。

增刪查改

在InnoDB中，給每行增長兩個隱藏字段來實現MVCC，一個用來記錄數據行的建立時間，另外一個用來記錄行的過時時間（刪除時間）。在實際操做中，存儲的並非時間，而是事務的版本號，每開啓一個新事務，事務的版本號就會遞增。

因而乎，默認的隔離級別（REPEATABLE READ）下，增刪查改變成了這樣：

SELECT
- 讀取建立版本小於或等於當前事務版本號，而且刪除版本爲空或大於當前事務版本號的記錄。這樣能夠保證在讀取以前記錄是存在的。
INSERT
- 將當前事務的版本號保存至行的建立版本號
UPDATE
- 新插入一行，並以當前事務的版本號做爲新行的建立版本號，同時將原記錄行的刪除版本號設置爲當前事務版本號
DELETE
- 將當前事務的版本號保存至行的刪除版本號

快照讀和當前讀

快照讀：讀取的是快照版本，也就是歷史版本

當前讀：讀取的是最新版本

普通的SELECT就是快照讀，而UPDATE、DELETE、INSERT、SELECT ... LOCK IN SHARE MODE、SELECT ... FOR UPDATE是當前讀。

一致性非鎖定讀和鎖定讀

鎖定讀

　　在一個事務中，標準的SELECT語句是不會加鎖，可是有兩種狀況例外。SELECT ... LOCK IN SHARE MODE 和 SELECT ... FOR UPDATE。

　　SELECT ... LOCK IN SHARE MODE

　　給記錄假設共享鎖，這樣一來的話，其它事務只能讀不能修改，直到當前事務提交

　　SELECT ... FOR UPDATE

　　給索引記錄加鎖，這種狀況下跟UPDATE的加鎖狀況是同樣的

一致性非鎖定讀

　　consistent read （一致性讀），InnoDB用多版原本提供查詢數據庫在某個時間點的快照。若是隔離級別是REPEATABLE READ，那麼在同一個事務中的全部一致性讀都讀的是事務中第一個這樣的讀讀到的快照；若是是READ COMMITTED，那麼一個事務中的每個一致性讀都會讀到它本身刷新的快照版本。Consistent read（一致性讀）是READ COMMITTED和REPEATABLE READ隔離級別下普通SELECT語句默認的模式。一致性讀不會給它所訪問的表加任何形式的鎖，所以其它事務能夠同時併發的修改它們。

悲觀鎖和樂觀鎖

悲觀鎖，正如它的名字那樣，數據庫老是認爲別人會去修改它所要操做的數據，所以在數據庫處理過程當中將數據加鎖。其實現依靠數據庫底層。

樂觀鎖，如它的名字那樣，老是認爲別人不會去修改，只有在提交更新的時候去檢查數據的狀態。一般是給數據增長一個字段來標識數據的版本。

鎖

有這樣三種鎖咱們須要瞭解

Record Locks（記錄鎖）：在索引記錄上加鎖。
Gap Locks（間隙鎖）：在索引記錄之間加鎖，或者在第一個索引記錄以前加鎖，或者在最後一個索引記錄以後加鎖。
Next-Key Locks：在索引記錄上加鎖，而且在索引記錄以前的間隙加鎖。它至關因而Record Locks與Gap Locks的一個結合。

假設一個索引包含如下幾個值：10,11,13,20。那麼這個索引的next-key鎖將會覆蓋如下區間：

(negative infinity, 10]
(10, 11]
(11, 13]
(13, 20]
(20, positive infinity)

瞭解了以上概念以後，接下來具體就簡單分析下REPEATABLE READ隔離級別是如何實現的

理論分析

之因此說是理論分析，是由於要是實際操做證實的話我也不知道怎麼去證實，畢竟做者水平實在有限。

可是，這並不意味着我在此胡說八道，有官方文檔爲證。

這段話的大體意思是，在默認的隔離級別中，普通的SELECT用的是一致性讀不加鎖。而對於鎖定讀、UPDATE和DELETE，則須要加鎖，至於加什麼鎖視狀況而定。若是你對一個惟一索引使用了惟一的檢索條件，那麼只需鎖定索引記錄便可；若是你沒有使用惟一索引做爲檢索條件，或者用到了索引範圍掃描，那麼將會使用間隙鎖或者next-key鎖以此來阻塞其它會話向這個範圍內的間隙插入數據。

做者曾經有一個誤區，認爲按照前面說MVCC下的增刪查改的行爲就不會出現任何問題，也不會出現不可重複讀和幻讀。但實際上是大錯特錯。

舉個很簡單的例子，假設事務A更新表中id=1的記錄，而事務B也更新這條記錄，而且B先提交，若是按照前面MVVC說的，事務A讀取id=1的快照版本，那麼它看不到B所提交的修改，此時若是直接更新的話就會覆蓋B以前的修改，這就不對了，可能B和A修改的不是一個字段，可是這樣一來，B的修改就丟失了，這是不容許的。

因此，在修改的時候必定不是快照讀，而是當前讀。

並且，前面也講過只有普通的SELECT纔是快照讀，其它諸如UPDATE、刪除都是當前讀。修改的時候加鎖這是必然的，同時爲了防止幻讀的出現還須要加間隙鎖。