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
4種事務的隔離級別,InnoDB如何巧妙實現?


分享到:


相關文章: