資料庫中的事務隔離級別和鎖的關係
我們都知道事務的幾種性質,資料庫為了維護這些性質,尤其是一致性和隔離性,一般使用加鎖這種方式。同時資料庫又是個高併發的應用,同一時間會有大量的併發訪問,如果加鎖過度,會極大的降低併發處理能力。所以對於加鎖的處理,可以說就是資料庫對於事務處理的精髓所在。這裡通過分析MySQL中InnoDB引擎的加鎖機制,來拋磚引玉,讓讀者更好的理解,在事務處理中資料庫到底做了什麼。
兩段鎖
資料庫遵循的是兩段鎖協議,將事務分成兩個階段,加鎖階段和解鎖階段(所以叫兩段鎖)
- 加鎖階段:在該階段可以進行加鎖操作。在對任何資料進行讀操作之前要申請並獲得S鎖(共享鎖,其它事務可以繼續加共享鎖,但不能加排它鎖),在進行寫操作之前要申請並獲得X鎖(排它鎖,其它事務不能再獲得任何鎖)
- 解鎖階段:當事務釋放了一個封鎖以後,事務進入解鎖階段,在該階段只能進行解鎖操作不能再進行加鎖操作。
事務 | 加鎖/解鎖處理 |
---|---|
begin; | |
insert into test ..... | 加insert對應的鎖 |
update test set... | 加update對應的鎖 |
delete from test .... | 加delete對應的鎖 |
commit; | 事務提交時,同時釋放insert、update、delete對應的鎖 |
這種方式雖然無法避免死鎖,但是兩段鎖協議可以保證事務的併發排程是序列化(序列化很重要,尤其是在資料恢復和備份的時候)的。
事務中的加鎖方式
兩段鎖實現事務的四種隔離級別
在讀取提交中,通過資料的讀取都是不加鎖的,但是資料的寫入、修改和刪除是需要加鎖的。
在可重複讀中,該sql第一次讀取到資料後,就將這些資料加鎖,其它事務無法修改這些資料,就可以實現可重複讀了。在資料庫操作中,為了有效保證併發讀取資料的正確性,提出的事務隔離級別。我們的資料庫鎖,也是為了構建這些隔離級別存在的。
隔離級別 | 髒讀(Dirty Read) | 不可重複讀(NonRepeatable Read) | 幻讀(Phantom Read) |
---|---|---|---|
未提交讀(Read uncommitted) | 可能 | 可能 | 可能 |
已提交讀(Read committed) | 不可能 | 可能 | 可能 |
可重複讀(Repeatable read) | 不可能 | 不可能 | 可能 |
可序列化(Serializable ) | 不可能 | 不可能 | 不可能 |
- 未提交讀(Read Uncommitted):允許髒讀,也就是可能讀取到其他會話中未提交事務修改的資料
- 提交讀(Read Committed):只能讀取到已經提交的資料。Oracle等多數資料庫預設都是該級別 (不重複讀)
- 可重複讀(Repeated Read):可重複讀。在同一個事務內的查詢都是事務開始時刻一致的,InnoDB預設級別。在SQL標準中,該隔離級別消除了不可重複讀,但是還存在幻象讀
- 序列讀(Serializable):完全序列化的讀,每次讀都需要獲得表級共享鎖,讀寫相互都會阻塞
Read Uncommitted這種級別,資料庫一般都不會用,而且任何操作都不會加鎖,這裡就不討論了。
MySQL中鎖的種類
MySQL中鎖的種類很多,有常見的表鎖和行鎖,也有新加入的Metadata Lock等等,表鎖是對一整張表加鎖,雖然可分為讀鎖和寫鎖,但畢竟是鎖住整張表,會導致併發能力下降,一般是做ddl處理時使用。
行鎖則是鎖住資料行,這種加鎖方法比較複雜,但是由於只鎖住有限的資料,對於其它資料不加限制,所以併發能力強,MySQL一般都是用行鎖來處理併發事務。這裡主要討論的也就是行鎖。
Read Committed(讀取提交內容)
在RC級別中,資料的讀取都是不加鎖的,但是資料的寫入、修改和刪除是需要加鎖的。效果如下
MySQL> show create table class_teacher \G\
Table: class_teacher
Create Table: CREATE TABLE `class_teacher` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`class_name` varchar(100) COLLATE utf8mb4_unicode_ci NOT NULL,
`teacher_id` int(11) NOT NULL,
PRIMARY KEY (`id`),
KEY `idx_teacher_id` (`teacher_id`)
) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci
1 row in set (0.02 sec)
MySQL> select * from class_teacher;
+----+--------------+------------+
| id | class_name | teacher_id |
+----+--------------+------------+
| 1 | 初三一班 | 1 |
| 3 | 初二一班 | 2 |
| 4 | 初二二班 | 2 |
+----+--------------+------------+
由於MySQL的InnoDB預設是使用的RR級別,所以我們先要將該session開啟成RC級別,並且設定binlog的模式
SET session transaction isolation level read committed;
SET SESSION binlog_format = 'ROW';(或者是MIXED)
事務A | 事務B |
---|---|
begin; | begin; |
update class_teacher set class_name='初三二班' where teacher_id=1; | update class_teacher set class_name='初三三班' where teacher_id=1; |
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction | |
commit; |
為了防止併發過程中的修改衝突,事務A中MySQL給teacher_id=1的資料行加鎖,並一直不commit(釋放鎖),那麼事務B也就一直拿不到該行鎖,wait直到超時。
這時我們要注意到,teacher_id是有索引的,如果是沒有索引的class_name呢?update class_teacher set teacher_id=3 where class_name = '初三一班';
那麼MySQL會給整張表的所有資料行的加行鎖。這裡聽起來有點不可思議,但是當sql執行的過程中,MySQL並不知道哪些資料行是 class_name = '初三一班'的(沒有索引嘛),如果一個條件無法通過索引快速過濾,儲存引擎層面就會將所有記錄加鎖後返回,再由MySQL Server層進行過濾。
但在實際使用過程當中,MySQL做了一些改進,在MySQL Server過濾條件,發現不滿足後,會呼叫unlock_row方法,把不滿足條件的記錄釋放鎖 (違背了二段鎖協議的約束)。這樣做,保證了最後只會持有滿足條件記錄上的鎖,但是每條記錄的加鎖操作還是不能省略的。可見即使是MySQL,為了效率也是會違反規範的。(參見《高效能MySQL》中文第三版p181)
這種情況同樣適用於MySQL的預設隔離級別RR。所以對一個數據量很大的表做批量修改的時候,如果無法使用相應的索引,MySQL Server過濾資料的的時候特別慢,就會出現雖然沒有修改某些行的資料,但是它們還是被鎖住了的現象。
Repeatable Read(可重讀)
這是MySQL中InnoDB預設的隔離級別。我們姑且分“讀”和“寫”兩個模組來講解。
讀
讀就是可重讀,可重讀這個概念是一事務的多個例項在併發讀取資料時,會看到同樣的資料行,有點抽象,我們來看一下效果。
RC(不可重讀)模式下的展現
事務A | 事務B | ||||||||
---|---|---|---|---|---|---|---|---|---|
begin; |
begin; |
||||||||
select id,class_name,teacher_id from class_teacher where teacher_id=1;
|
|||||||||
update class_teacher set class_name='初三三班' where id=1; |
|||||||||
commit; | |||||||||
select id,class_name,teacher_id from class_teacher where teacher_id=1;
讀到了事務B修改的資料,和第一次查詢的結果不一樣,是不可重讀的。 |
|||||||||
commit; |
事務B修改id=1的資料提交之後,事務A同樣的查詢,後一次和前一次的結果不一樣,這就是不可重讀(重新讀取產生的結果不一樣)。這就很可能帶來一些問題,那麼我們來看看在RR級別中MySQL的表現:
事務A | 事務B | 事務C | |||||||
---|---|---|---|---|---|---|---|---|---|
begin; |
begin; |
begin; |
|||||||
select id,class_name,teacher_id from class_teacher where teacher_id=1;
|
|||||||||
update class_teacher set class_name='初三三班' where id=1; commit; |
|||||||||
insert into class_teacher values (null,'初三三班',1); commit; | |||||||||
select id,class_name,teacher_id from class_teacher where teacher_id=1;
沒有讀到事務B修改的資料,和第一次sql讀取的一樣,是可重複讀的。 沒有讀到事務C新新增的資料。 |
|||||||||
commit; |
我們注意到,當teacher_id=1時,事務A先做了一次讀取,事務B中間修改了id=1的資料,並commit之後,事務A第二次讀到的資料和第一次完全相同。所以說它是可重讀的。那麼MySQL是怎麼做到的呢?這裡姑且賣個關子,我們往下看。
不可重複讀和幻讀的區別
很多人容易搞混不可重複讀和幻讀,確實這兩者有些相似。但不可重複讀重點在於update和delete,而幻讀的重點在於insert。
如果使用鎖機制來實現這兩種隔離級別,在可重複讀中,該sql第一次讀取到資料後,就將這些資料加鎖,其它事務無法修改這些資料,就可以實現可重複讀了。但這種方法卻無法鎖住insert的資料,所以當事務A先前讀取了資料,或者修改了全部資料,事務B還是可以insert資料提交,這時事務A就會發現莫名其妙多了一條之前沒有的資料,這就是幻讀,不能通過行鎖來避免。需要Serializable隔離級別 ,讀用讀鎖,寫用寫鎖,讀鎖和寫鎖互斥,這麼做可以有效的避免幻讀、不可重複讀、髒讀等問題,但會極大的降低資料庫的併發能力。
所以說不可重複讀和幻讀最大的區別,就在於如何通過行鎖機制來解決他們產生的問題。
上文說的,是使用悲觀鎖機制來處理這兩種問題,但是MySQL、ORACLE、PostgreSQL等成熟的資料庫,出於效能考慮,都是使用了以樂觀鎖為理論基礎的MVCC(多版本併發控制)來避免這兩種問題。
悲觀鎖和樂觀鎖
- 悲觀鎖
正如其名,它指的是對資料被外界修改持保守態度,因此,在整個資料處理過程中,將資料處於鎖定狀態。悲觀鎖的實現,往往依靠資料庫提供的鎖機制。
在悲觀鎖的情況下,為了保證事務的隔離性,就需要一致性鎖定讀。讀取資料時給加鎖,其它事務無法修改這些資料。修改刪除資料時也要加鎖,其它事務無法讀取這些資料。
- 樂觀鎖
相對悲觀鎖而言,樂觀鎖機制採取了更加寬鬆的加鎖機制。悲觀鎖大多數情況下依靠資料庫的鎖機制實現,以保證操作最大程度的獨佔性。但隨之而來的就是資料庫效能的大量開銷,特別是對長事務而言,這樣的開銷往往無法承受。
而樂觀鎖機制在一定程度上解決了這個問題。樂觀鎖,大多是基於資料版本併發機制實現。何謂資料版本?即為資料增加一個版本標識,在基於資料庫表的版本解決方案中,一般是通過為資料庫表增加一個 “version” 欄位來實現。讀取出資料時,將此版本號一同讀出,之後更新時,對此版本號加一。此時,將提交資料的版本資料與資料庫表對應記錄的當前版本資訊進行比對,如果提交的資料版本號大於資料庫表當前版本號,則予以更新,否則認為是過期資料。要說明的是,MVCC的實現沒有固定的規範,每個資料庫都會有不同的實現方式,這裡討論的是InnoDB的MVCC。
Serializable
這個級別很簡單,讀加共享鎖,寫加排他鎖,讀寫互斥。使用的悲觀鎖的理論,實現簡單,資料更加安全,但是併發能力非常差。如果你的業務併發的特別少或者沒有併發,同時又要求資料及時可靠的話,可以使用這種模式。
這裡要吐槽一句,不要看到select就說不會加鎖了,在Serializable這個級別,還是會加鎖的!