innodb是如何巧妙實現事務隔離級別

摘要： 之前的文章mysql鎖機制詳解中我們詳細講解了innodb的鎖機制，鎖機制是用來保證在併發情況下資料的準確性，而要保證資料準確通常需要事務的支援，而mysql儲存引擎innodb是通過鎖機制來巧妙地實現事務的隔離特性中的4種隔離級別。 事務ACID特性，其中I代表隔離性(Isolat...

之前的文章mysql鎖機制詳解中我們詳細講解了innodb的鎖機制，鎖機制是用來保證在併發情況下資料的準確性，而要保證資料準確通常需要事務的支援，而mysql儲存引擎innodb是通過鎖機制來巧妙地實現事務的隔離特性中的4種隔離級別。

事務ACID特性，其中I代表隔離性(Isolation)。隔離性是指，多個使用者的併發事務訪問同一個資料庫時，一個使用者的事務不應該被其他使用者的事務干擾，多個併發事務之間要相互隔離。

1. 事務之間如何互相干擾

一個事務是如何幹擾其他事務呢？舉個例子，有如下表：

create table lock_example(id smallint(10),name varchar(20),primary key id)engine=innodb;

表中有如下資料：

1, zhangsan
2, lisi
3, wangwu

demo1:

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

insert into t values(4, 'zhaoliu');

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

select * from t;

如果事務B能夠讀取到(4, zhaoliu)這條記錄，說明事務A就對事務B產生了影響，這種影響叫做“讀髒 ”，即讀到了未提交事務操作的記錄。

demo2:

事務A，先執行：

select * from t where id=1;

結果集為

1,zhangsan

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

update t set name=xxx where id=1;

commit;

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

select * from t where id=1;

結果集為：

1, xxx

這次是已提交事務B對事務A產生的影響，這種影響叫做“不可重複讀 ”，即一個事務內相同的查詢，卻得到了不同的結果。

demo3:

事務A，先執行：

select * from t where id>3;
　結果集為：
　NULL

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

insert into t values(4, zhaoliu);

commit;

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

insert into t values(4, xxoo);

結果集為：

Error : duplicate key!

你可能會想。。。你TM在逗我？查了id>3為空集，insert id=4時又告訴我PK衝突？→_→

這次是已提交事務B對事務A產生的影響，這種影響叫做“幻讀 ”。

如上，併發的事務可能導致其他事務出現讀髒 、不可重複讀 、幻讀 。為了避免如上情況出現，innodb又做了哪些努力呢？

2. InnoDB實現了哪幾種事務的隔離級別?

InnoDB實現了四種不同事務的隔離級別：

• 讀未提交(Read Uncommitted)
• 讀提交(Read Committed, RC)
• 可重複讀(Repeated Read, RR)
• 序列化(Serializable)

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

3. 四種事務的隔離級別，innodb如何實現?

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

a. 讀未提交(Read Uncommitted)

這種事務隔離級別下，select語句不加鎖，也不是快照讀。

SELECT statements are performed in a nonlocking fashion.

此時，可能讀取到不一致的資料，即“讀髒”。這是併發最高，一致性最差的隔離級別。

b. 讀提交(Read Committed, RC)

1. 普通select是快照讀；
2. 加鎖的select, update, delete等語句，除了在外來鍵約束檢查(foreign-key constraint checking)以及重複鍵檢查(duplicate-key checking)時會封鎖區間，其他時刻都只使用記錄鎖 ；
3. 間隙鎖(gap lock)、臨建鎖(next-key lock)在該級別下失效；

  此時，其他事務的插入依然可以執行，就可能導致，讀取到幻影記錄。該級別是最常使用的。而且如果是不上鎖的select，可能產生不可重複讀。

該級別下是通過快照讀來防止讀髒的。因為在該級別下的快照讀總是能讀到最新的行資料快照，當然，必須是已提交事務寫入的，所以可能產生不可重複讀。

c. 可重複讀(Repeated Read, RR)

這是InnoDB預設的隔離級別，在RR下：

1. 普通的select使用快照讀(snapshot read)，這是一種不加鎖的一致性讀(Consistent Nonlocking Read)，底層使用MVCC來實現；
2. 加鎖的select(select ... in share mode / select ... for update), update, delete等語句，它們的鎖，依賴於它們是否在唯一索引(unique index)上使用了唯一的查詢條件(unique search condition，此時使用記錄鎖)，或者範圍查詢條件(range-type search condition，此時使用間隙鎖或臨鍵鎖)；
3. 在唯一索引上使用唯一的查詢條件，會使用記錄鎖(record lock)，而不會封鎖記錄之間的間隔，即不會使用間隙鎖(gap lock)與臨鍵鎖(next-key lock)；
4. 範圍查詢條件或者是非唯一索引，會使用間隙鎖與臨鍵鎖，鎖住索引記錄之間的範圍，避免範圍間插入記錄，以避免產生幻影行記錄，以及避免不可重複讀；

在該級別下

• 通過快照讀以及鎖定區間來實現避免產生幻讀和不可重複讀；

• 某個事務首次read記錄的時間為T，未來不會讀取到T時間之後已提交事務寫入的記錄，以保證連續相同的read讀到相同的結果集，這可以防止不可重複讀；

• RR下是通過間隙鎖，臨鍵鎖來解決幻影讀問題；

d. 序列化(Serializable)

這種事務的隔離級別下，所有select語句都會被隱式的轉化為select ... in share mode，也就是預設上共享讀鎖(S鎖)。

所以，如果事務A先執行如下sql之後，會嘗試獲取所查詢行的IS鎖(和別的IS、IX鎖是相容的)，這時別的事務也能獲取這些行的IS鎖甚至是S鎖，但是如果接下來，事務A如果update或delete其中的某些行，這時就獲取了X鎖，別的事務即便是執行普通的select語句也會阻塞，因為它們嘗試獲取IS鎖，但是IS鎖和X鎖是互斥的，這樣就避免了讀髒、不可重複讀以及幻讀，所有事務就只能串行了。

select ... ;

這是一致性最好的，但併發性最差的隔離級別。高併發量的場景下，幾乎不會使用上述a和d這兩種隔離級別。

4. 總結

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

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

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

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

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

• 序列化：select隱式轉化為select ... in share mode，會被update與delete互斥；

  InnoDB預設的隔離級別是RR，用得最多的隔離級別是RC