Categories
程式開發

深入理解MySQL中事務隔離級別的實現原理


前言

說到數據庫事務,大家腦子裡一定很容易蹦出一堆事務的相關知識,如事務的ACID特性,隔離級別,解決的問題(臟讀,不可重複讀,幻讀)等等,但是可能很少有人真正的清楚事務的這些特性又是怎麼實現的,為什麼要有四個隔離級別。

今天我們就先來聊聊MySQL中事務的隔離性的實現原理,後續還會繼續出文章分析其他特性的實現原理。

當然MySQL博大精深,文章疏漏之處在所難免,歡迎批評指正。

說明

MySQL的事務實現邏輯是位於引擎層的,並且不是所有的引擎都支持事務的,下面的說明都是以InnoDB引擎為基準。

定義

隔離性(isolation)指的是不同事務先後提交並執行後,最終呈現出來的效果是串行的,也就是說,對於事務來說,它在執行過程中,感知到的數據變化應該只有自己操作引起的,不存在其他事務引發的數據變化。

隔離性解決的是並發事務出現的問題。

標準SQL隔離級別

隔離性最簡單的實現方式就是各個事務都串行執行了,如果前面的事務還沒有執行完畢,後面的事務就都等待。但是這樣的實現方式很明顯並發效率不高,並不適合在實際環境中使用。

為了解決上述問題,實現不同程度的並發控制,SQL的標準制定者提出了不同的隔離級別:未提交讀(read uncommitted)、提交讀(read committed)、可重複讀(repeatable read)、序列化讀(serializable)。其中最高級隔離級別就是序列化讀,而在其他隔離級別中,由於事務是並發執行的,所以或多或少允許出現一些問題。見以下的矩陣表:

深入理解MySQL中事務隔離級別的實現原理 1

注意,MySQL的InnoDB引擎在提交讀級別通過MVCC解決了不可重複讀的問題,在可重複讀級別通過間隙鎖解決了幻讀問題,具體見下面的分析。

實現原理

標準SQL事務隔離級別實現原理

我們上面遇到的問題其實就是並發事務下的控制問題,解決並發事務的最常見方式就是悲觀並發控制了(也就是數據庫中的鎖)。標準SQL事務隔離級別的實現是依賴鎖的,我們來看下具體是怎麼實現的:

深入理解MySQL中事務隔離級別的實現原理 2

可以看到,在只使用鎖來實現隔離級別的控制的時候,需要頻繁的加鎖解鎖,而且很容易發生讀寫的衝突(例如在RC級別下,事務A更新了數據行1,事務B則在事務A提交前讀取數據行1都要等待事務A提交並釋放鎖)。

為了不加鎖解決讀寫衝突的問題,MySQL引入了MVCC機制,詳細可見我以前的分析文章:一文讀懂數據庫中的樂觀鎖和悲觀鎖和MVCC“。

InnoDB事務隔離級別實現原理

在往下分析之前,我們有幾個概念需要先了解下:

1、鎖定讀和一致性非鎖定讀

鎖定讀:在一個事務中,主動給讀加鎖,如SELECT … LOCK IN SHARE MODE 和SELECT … FOR UPDATE。分別加上了行共享鎖和行排他鎖。鎖的分類可見我以前的分析文章:你應該了解的MySQL鎖分類“)。

https://dev.mysql.com/doc/refman/8.0/zh-CN/innodb-locking-reads.html

一致性非鎖定讀:InnoDB使用MVCC向事務的查詢提供某個時間點的數據庫快照。查詢會看到在該時間點之前提交的事務所做的更改,而不會看到稍後或未提交的事務所做的更改(本事務除外)。也就是說在開始了事務之後,事務看到的數據就都是事務開啟那一刻的數據了,其他事務的後續修改不會在本次事務中可見。

Consistent read是InnoDB在RC和RR隔離級別處理SELECT語句的默認模式。一致性非鎖定讀不會對其訪問的表設置任何鎖,因此,在對錶執行一致性非鎖定讀的同時,其它事務可以同時並發的讀取或者修改它們。

https://dev.mysql.com/doc/refman/8.0/zh-CN/innodb-consistent-read.html

2、當前讀和快照讀

當前讀

讀取的是最新版本,像UPDATE、DELETE、INSERT、SELECT … LOCK IN SHARE MODE、SELECT … FOR UPDATE這些操作都是一種當前讀,為什麼叫當前讀?就是它讀取的是記錄的最新版本,讀取時還要保證其他並發事務不能修改當前記錄,會對讀取的記錄進行加鎖。

快照讀

讀取的是快照版本,也就是歷史版本,像不加鎖的SELECT操作就是快照讀,即不加鎖的非阻塞讀;快照讀的前提是隔離級別不是未提交讀和序列化讀級別,因為未提交讀總是讀取最新的數據行,而不是符合當前事務版本的數據行,而序列化讀則會對錶加鎖。

3、隱式鎖定和顯式鎖定

隱式鎖定

InnoDB在事務執行過程中,使用兩階段鎖協議(不主動進行顯示鎖定的情況):

隨時都可以執行鎖定,InnoDB會根據隔離級別在需要的時候自動加鎖;鎖只有在執行commit或者rollback的時候才會釋放,並且所有的鎖都是在同一時刻被釋放。

顯式鎖定

InnoDB也支持通過特定的語句進行顯示鎖定(存儲引擎層)

select ... lock in share mode //共享锁
select ... for update //排他锁

MySQL Server層的顯示鎖定:

lock table
unlock table

了解完上面的概念後,我們來看下InnoDB的事務具體是怎麼實現的(下面的讀都指的是非主動加鎖的select)

深入理解MySQL中事務隔離級別的實現原理 3

一些常見誤區

幻讀到底包不包括了delete的情況?

不可重複讀:前後多次讀取一行,數據內容不一致,針對其他事務的update和delete操作。為了解決這個問題,使用行共享鎖,鎖定到事務結束(也就是RR級別,當然MySQL使用MVCC在RC級別就解決了這個問題)

幻讀:當同一個查詢在不同時間生成不同的行集合時就是出現了幻讀,針對的是其他事務的insert操作,為了解決這個問題,鎖定整個表到事務結束(也就是S級別,當然MySQL使用間隙鎖在RR級別就解決了這個問題)

網上很多文章提到幻讀和提交讀的時候,有的說幻讀包括了delete的情況,有的說delete應該屬於提交讀的問題,那到底真相如何呢?我們實際來看下MySQL的官方文檔(如下)

當同一查詢在不同時間產生不同的行集時,在事務內就會發生所謂的幻象問題。 例如,如果 選擇“)被執行兩次,但是第二次返回的行卻不是第一次返回,該行是“幻像”行。https://dev.mysql.com/doc/refman/5.7/zh-CN/innodb-next-key-locking.html

可以看到,幻讀針對的是結果集前後發生變化,所以看起來delete的情況應該歸為幻讀,但是我們實際分析下上面列出的標準SQL在RR級別的實現原理就知道,標準SQL的RR級別是會對查到的數據行加行共享鎖,所以這時候其他事務想刪除這些數據行其實是做不到的,所以在RR下,不會出現因delete而出現幻讀現象,也就是幻讀不包含delete的情況。

MVCC能解決了幻讀問題?

網上很多文章會說MVCC或者MVCC+間隙鎖解決了幻讀問題,實際上MVCC並不能解決幻讀問題。如以下的例子:

begin;

#假设users表为空,下面查出来的数据为空

select * from users; #没有加锁

#此时另一个事务提交了,且插入了一条id=1的数据

select * from users; #读快照,查出来的数据为空

update users set name="mysql" where id=1;#update是当前读,所以更新成功,并生成一个更新的快照

select * from users; #读快照,查出来id为1的一条记录,因为MVCC可以查到当前事务生成的快照

commit;

可以看到前後查出來的數據行不一致,發生了幻讀。所以說只有MVCC是不能解決幻讀問題的,解決幻讀問題靠的是間隙鎖。如下:

begin;

#假设users表为空,下面查出来的数据为空

select * from users lock in share mode; #加上共享锁

#此时另一个事务B想提交且插入了一条id=1的数据,由于有间隙锁,所以要等待

select * from users; #读快照,查出来的数据为空

update users set name="mysql" where id=1;#update是当前读,由于不存在数据,不进行更新

select * from users; #读快照,查出来的数据为空

commit;

#事务B提交成功并插入数据

注意,RR級別下想解決幻讀問題,需要我們顯式加鎖,不然查詢的時候還是不會加鎖的。