幾種事務的隔離級別，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)
-
範圍查詢條件，會使用間隙鎖與臨鍵鎖，鎖住索引記錄之間的範圍，避免範圍間插入記錄，以避免產生幻影行記錄，以及避免不可重複的讀
畫外音：這一段有點繞，多讀幾遍。
四，讀提交(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
--------------------- 本文來自 架構師之路_ 的CSDN 部落格 ，全文地址請點選：https://blog.csdn.net/z50L2O08e2u4afToR9A/article/details/82186189?utm_source=copy