Innodb中的事務隔離級別和鎖的關係（轉）

轉載自：http://tech.meituan.com/innodb-lock.html

咱們都知道事務的幾種性質，數據庫爲了維護這些性質，尤爲是一致性和隔離性，通常使用加鎖這種方式。同時數據庫又是個高併發的應用，同一時間會有大量的併發訪問，若是加鎖過分，會極大的下降併發處理能力。因此對於加鎖的處理，能夠說就是數據庫對於事務處理的精髓所在。這裏經過分析MySQL中InnoDB引擎的加鎖機制，來拋磚引玉，讓讀者更好的理解，在事務處理中數據庫到底作了什麼。

一次封鎖or兩段鎖？

由於有大量的併發訪問，爲了預防死鎖，通常應用中推薦使用一次封鎖法，就是在方法的開始階段，已經預先知道會用到哪些數據，而後所有鎖住，在方法運行以後，再所有解鎖。這種方式能夠有效的避免循環死鎖，但在數據庫中卻不適用，由於在事務開始階段，數據庫並不知道會用到哪些數據。
數據庫遵循的是兩段鎖協議，將事務分紅兩個階段，加鎖階段和解鎖階段（因此叫兩段鎖）

• 加鎖階段：在該階段能夠進行加鎖操做。在對任何數據進行讀操做以前要申請並得到S鎖（共享鎖，其它事務能夠繼續加共享鎖，但不能加排它鎖），在進行寫操做以前要申請並得到X鎖（排它鎖，其它事務不能再得到任何鎖）。加鎖不成功，則事務進入等待狀態，直到加鎖成功才繼續執行。
• 解鎖階段：當事務釋放了一個封鎖之後，事務進入解鎖階段，在該階段只能進行解鎖操做不能再進行加鎖操做。

事務	加鎖/解鎖處理
begin；
insert into test .....	加insert對應的鎖
update test set...	加update對應的鎖
delete from test ....	加delete對應的鎖
commit;	事務提交時，同時釋放insert、update、delete對應的鎖

這種方式雖然沒法避免死鎖，可是兩段鎖協議能夠保證事務的併發調度是串行化（串行化很重要，尤爲是在數據恢復和備份的時候）的。

事務中的加鎖方式

事務的四種隔離級別

在數據庫操做中，爲了有效保證併發讀取數據的正確性，提出的事務隔離級別。咱們的數據庫鎖，也是爲了構建這些隔離級別存在的。

隔離級別	髒讀（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; id class_name teacher_id 1 初三二班 1 2 初三一班 1
	update class_teacher set class_name='初三三班' where id=1;
	commit;
select id,class_name,teacher_id from class_teacher where teacher_id=1; id class_name teacher_id 1 初三三班 1 2 初三一班 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; id class_name teacher_id 1 初三二班 1 2 初三一班 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; id class_name teacher_id 1 初三二班 1 2 初三一班 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 ）記錄機制實現。何謂數據版本？即爲數據增長一個版本標識，在基於數據庫表的版本解決方案中，通常是經過爲數據庫表增長一個 「version」 字段來實現。讀取出數據時，將此版本號一同讀出，以後更新時，對此版本號加一。此時，將提交數據的版本數據與數據庫表對應記錄的當前版本信息進行比對，若是提交的數據版本號大於數據庫表當前版本號，則予以更新，不然認爲是過時數據。要說明的是，MVCC的實現沒有固定的規範，每一個數據庫都會有不一樣的實現方式，這裏討論的是InnoDB的MVCC。

 

Serializable

這個級別很簡單，讀加共享鎖，寫加排他鎖，讀寫互斥。使用的悲觀鎖的理論，實現簡單，數據更加安全，可是併發能力很是差。若是你的業務併發的特別少或者沒有併發，同時又要求數據及時可靠的話，可使用這種模式。

這裏要吐槽一句，不要看到select就說不會加鎖了，在Serializable這個級別，仍是會加鎖的！