4種事務的隔離級別，InnoDB如何巧妙實現？

事務ACID特性，其中I表明隔離性(Isolation)。

什麼是事務的隔離性？

隔離性是指，多個用戶的併發事務訪問同一個數據庫時，一個用戶的事務不該該被其餘用戶的事務干擾，多個併發事務之間要相互隔離。

一個事務怎麼會干擾其餘事務呢？

我們舉例子來講明，假設有InnoDB表：

t(id PK, name);

表中有三條記錄：

1, shenjian

2, zhangsan

3, lisi

case 1

事務A，先執行，處於未提交的狀態：

insert into t values(4, wangwu);

事務B，後執行，也未提交：

select * from t;

若是事務B可以讀取到(4, wangwu)這條記錄，事務A就對事務B產生了影響，這個影響叫作「讀髒」，讀到了未提交事務操做的記錄。

case 2

事務A，先執行：

select * from t where id=1;

結果集爲：

1, shenjian

事務B，後執行，而且提交：

update t set name=xxoo where id=1;

commit;

事務A，再次執行相同的查詢：

select * from t where id=1;

結果集爲：

1, xxoo

此次是已提交事務B對事務A產生的影響，這個影響叫作「不可重複讀」，一個事務內相同的查詢，獲得了不一樣的結果。

case 3

事務A，先執行：

select * from t where id>3;

結果集爲：

NULL

事務B，後執行，而且提交：

insert into t values(4, wangwu);

commit;

事務A，首次查詢了id>3的結果爲NULL，因而想插入一條爲4的記錄：

insert into t values(4, xxoo);

結果集爲：

Error : duplicate key!

事務A的心裏OS是：你TM在逗我，查了id>3爲空集，insert id=4告訴我PK衝突？

此次是已提交事務B對事務A產生的影響，這個影響叫作「幻讀」。

能夠看到，併發的事務可能致使其餘事務：

• 讀髒

• 不可重複讀

• 幻讀

InnoDB實現了哪幾種事務的隔離級別？

按照SQL92標準，InnoDB實現了四種不一樣事務的隔離級別：

• 讀未提交(Read Uncommitted)

• 讀提交(Read Committed, RC)

• 可重複讀(Repeated Read, RR)

• 串行化(Serializable)

不一樣事務的隔離級別，其實是一致性與併發性的一個權衡與折衷。

InnoDB的四種事務的隔離級別，分別是怎麼實現的？

InnoDB使用不一樣的鎖策略(Locking Strategy)來實現不一樣的隔離級別。

一，讀未提交(Read Uncommitted)

這種事務隔離級別下，select語句不加鎖。

畫外音：官方的說法是

SELECT statements are performed in a nonlocking fashion.

此時，可能讀取到不一致的數據，即「讀髒」。這是併發最高，一致性最差的隔離級別。

二，串行化(Serializable)

這種事務的隔離級別下，全部select語句都會被隱式的轉化爲select ... in share mode.

這可能致使，若是有未提交的事務正在修改某些行，全部讀取這些行的select都會被阻塞住。

畫外音：官方的說法是

To force a plain SELECT to block if other transactions have modified the selected rows.

這是一致性最好的，但併發性最差的隔離級別。

在互聯網大數據量，高併發量的場景下，幾乎不會使用上述兩種隔離級別。

三，可重複讀(Repeated Read, RR)

這是InnoDB默認的隔離級別，在RR下：

(1)普通的select使用快照讀(snapshot read)，這是一種不加鎖的一致性讀(Consistent Nonlocking Read)，底層使用MVCC來實現，具體的原理在《InnoDB併發如此高，緣由居然在這？》中有詳細的描述；

(2)加鎖的select(select ... in share mode / select ... for update), update, delete等語句，它們的鎖，依賴於它們是否在惟一索引(unique index)上使用了惟一的查詢條件(unique search condition)，或者範圍查詢條件(range-type search condition)：

• 在惟一索引上使用惟一的查詢條件，會使用記錄鎖(record lock)，而不會封鎖記錄之間的間隔，即不會使用間隙鎖(gap lock)與臨鍵鎖(next-key lock)

• 範圍查詢條件，會使用間隙鎖與臨鍵鎖，鎖住索引記錄之間的範圍，避免範圍間插入記錄，以免產生幻影行記錄，以及避免不可重複的讀

畫外音：這一段有點繞，多讀幾遍。

關於記錄鎖，間隙鎖，臨鍵鎖的更多說明，詳見《InnoDB，select爲啥會阻塞insert？》。

四，讀提交(Read Committed, RC)

這是互聯網最經常使用的隔離級別，在RC下：

(1)普通讀是快照讀；

(2)加鎖的select, update, delete等語句，除了在外鍵約束檢查(foreign-key constraint checking)以及重複鍵檢查(duplicate-key checking)時會封鎖區間，其餘時刻都只使用記錄鎖；

此時，其餘事務的插入依然能夠執行，就可能致使，讀取到幻影記錄。

總結

• 併發事務之間相互干擾，可能致使事務出現讀髒，不可重複度，幻讀等問題

• InnoDB實現了SQL92標準中的四種隔離級別

(1)讀未提交：select不加鎖，可能出現讀髒；

(2)讀提交(RC)：普通select快照讀，鎖select /update /delete 會使用記錄鎖，可能出現不可重複讀；

(3)可重複讀(RR)：普通select快照讀，鎖select /update /delete 根據查詢條件狀況，會選擇記錄鎖，或者間隙鎖/臨鍵鎖，以防止讀取到幻影記錄；

(4)串行化：select隱式轉化爲select ... in share mode，會被update與delete互斥；

• InnoDB默認的隔離級別是RR，用得最多的隔離級別是RC

或許有朋友問，爲啥沒提到insert？能夠查閱《InnoDB併發插入，竟然使用意向鎖？》。 

Refer：

[1] 4種事務的隔離級別，InnoDB如何巧妙實現？

https://mp.weixin.qq.com/s/x_7E2R2i27Ci5O7kLQF0UA