事務(wù)的四種隔離級別
- 1、未提交讀（Read uncommitted）
一個事務(wù)讀取到其他事務(wù)未提交的數(shù)據(jù)湘纵，是級別最低的隔離機制；
- 2、提交讀（Read committed)
一個事務(wù)讀取到其他事務(wù)提交后的數(shù)據(jù)悦冀；
- 3、可重復(fù)讀（Repeatable read）
一個事務(wù)對同一份數(shù)據(jù)讀取到的相同睛琳，不在乎其他事務(wù)對數(shù)據(jù)的修改盒蟆；
- 4、序列化（Serializable）
事務(wù)串行化執(zhí)行师骗，隔離級別最高茁影，犧牲了系統(tǒng)的并發(fā)性。
并發(fā)中事務(wù)的問題
- 問題1丧凤、臟讀
事務(wù)A讀取了事務(wù)B更新的數(shù)據(jù)募闲，然后B回滾操作，那么A讀取到的數(shù)據(jù)是臟數(shù)據(jù)
- 問題2愿待、不可重復(fù)讀
事務(wù) A 多次讀取同一數(shù)據(jù)浩螺，事務(wù) B 在事務(wù)A多次讀取的過程中靴患，對數(shù)據(jù)作了更新并提交，導(dǎo)致事務(wù)A多次讀取同一數(shù)據(jù)時要出，結(jié)果 不一致
- 問題3鸳君、幻讀
同一事務(wù)中對同一范圍的數(shù)據(jù)進行讀取，結(jié)果卻多出了數(shù)據(jù)或者少了數(shù)據(jù)患蹂，這就叫幻讀或颊。（如同一事務(wù)對id<10的范圍進行2次查詢，第一次出現(xiàn)id=8传于、9的兩條數(shù)據(jù)囱挑，第二次出現(xiàn)id=7、8沼溜、9的3條數(shù)據(jù)）
不可重復(fù)讀的和幻讀很容易混淆平挑，不可重復(fù)讀側(cè)重于修改，幻讀側(cè)重于新增或刪除系草。解決不可重復(fù)讀的問題只需鎖住滿足條件的行通熄，解決幻讀需要鎖表。
不同的隔離級別針對上述3個問題的解決能力找都，如下表:
| 隔離級別 | 臟讀 | 不可重復(fù)讀 | 幻讀 |
|---|---|---|---|
| 未提交讀 | 可能 | 可能 | 可能 |
| 提交讀 | 不可能 | 可能 | 可能 |
| 可重復(fù)讀 | 不可能 | 不可能 | 可能 |
| 序列化 | 不可能 | 不可能 | 不可能 |
MVCC
InnoDB 默認(rèn)的隔離級別是可重復(fù)讀（RR）唇辨，InnoDB是通過MVCC（多版本并發(fā)控制）來實現(xiàn)可重復(fù)讀的
概念
在InnoDB中，給每行增加兩個隱藏字段來實現(xiàn)MVCC能耻，一個用來記錄數(shù)據(jù)行的創(chuàng)建時間赏枚，另一個用來記錄行的過期時間（刪除時間）。在實際操作中嚎京，存儲的并不是時間嗡贺，而是事務(wù)的版本號，每開啟一個新事務(wù)鞍帝，事務(wù)的版本號就會遞增
于是乎诫睬，默認(rèn)的隔離級別（REPEATABLE READ）下，增刪查改變成了這樣：
- select:
讀取創(chuàng)建版本小于或等于當(dāng)前事務(wù)版本號帕涌，并且刪除版本為空或大于當(dāng)前事務(wù)版本號的記錄摄凡。這樣可以保證在讀取之前記錄是存在的
- INSERT:
將當(dāng)前事務(wù)的版本號保存至行的創(chuàng)建版本號。
- UPDATE:
新插入一行蚓曼，并以當(dāng)前事務(wù)的版本號作為新行的創(chuàng)建版本號亲澡，同時將原記錄行的刪除版本號設(shè)置為當(dāng)前事務(wù)版本號。
- DELETE:
將當(dāng)前事務(wù)的版本號保存至行的刪除版本號纫版。
快照讀和當(dāng)前讀
- 快照讀：
讀取的是快照版本床绪，也就是歷史版本；
- 當(dāng)前讀:
讀取的是最新版本
普通的SELECT就是快照讀，而UPDATE癞己、DELETE膀斋、INSERT、SELECT ... LOCK IN SHARE MODE痹雅、SELECT ... FOR UPDATE是當(dāng)前讀
結(jié)論:
如果隔離級別是REPEATABLE READ仰担，那么在同一個事務(wù)中的所有普通select讀讀到的都是事務(wù)第一個讀到的快照，如此實現(xiàn)了可重復(fù)讀绩社；而對于當(dāng)前讀（UPDATE摔蓝、DELETE、INSERT愉耙、SELECT ... LOCK IN SHARE MODE贮尉、SELECT ... FOR UPDATE），InnoDB 通過加鎖來實現(xiàn)可重復(fù)讀劲阎，且InnoDB 加鎖同時解決了幻讀問題
鎖的類型
InnoDB 引入以下三種鎖類型：
- Record Locks（記錄鎖）：
在索引記錄上加鎖绘盟，即行鎖鸠真，鎖住當(dāng)前行
- Gap Locks（間隙鎖）
在索引記錄之間加鎖悯仙，或者在第一個索引記錄之前加鎖，或者在最后一個索引記錄之后加鎖吠卷。
- Next-Key Locks：
在索引記錄上加鎖锡垄，并且在索引記錄之前的間隙加鎖。它相當(dāng)于是Record Locks與Gap Locks的一個結(jié)合祭隔。
假設(shè)一個索引包含以下幾個值：10,11,13,20货岭。那么這個索引的next-key鎖將會覆蓋以下區(qū)間：(-oo, 10]、(10, 11]疾渴、(11, 13]千贯、(13, 20]、(20, +oo)搞坝。
MySQL InnoDB 通過間隙鎖解決了幻讀問題搔谴。以下通過實際的案例分析來介紹InnoDB 是如果解決幻讀問題的。
案例分析
在對SQL進行加鎖分析前桩撮，需要明確表的結(jié)構(gòu)和索引類型敦第。在不知道索引的情況下直接給出一條SQL來分析如果加鎖是沒有任何意義的
以下以用戶表（t_user）為例（id為主鍵，name為唯一索引店量，age為一般索引芜果，address無索引）分析不同索引條件的加鎖表現(xiàn)
- 1、主鍵索引
例：delete from t_user where id=120;
條件為主鍵融师，此時鎖住聚簇索引中對應(yīng)的行記錄：即Record Locks鎖住id=120的行記錄,此種情況下右钾，其他事務(wù)除了不能刪除、更新此條記錄外，其他插入其他行舀射、更新其他行都行灭将。
- 2、唯一索引
例：delete from t_user where name='n20';
條件為唯一索引后控，鎖住索引記錄庙曙，同時鎖住聚簇索引中的對應(yīng)行記錄：
- 3、一般索引
例：delete from t_user where age=20;
與主鍵和唯一索引不同的是浩淘，一般索引的記錄是允許重復(fù)的捌朴；換句話說，如果我們單純地給索引加記錄鎖時张抄，其他事務(wù)依然可以插入砂蔽，也就有可能出現(xiàn)幻讀問題了。
所以除了給對應(yīng)索引記錄加上記錄鎖之外署惯，還要給Gap加上鎖左驾。
- 4、無索引
delete from t_user where address='a20'极谊，因為無法精準(zhǔn)定位诡右，InnoDB選擇將聚簇索引中的所有行以及間隙都鎖起來，功能上已經(jīng)等于鎖表了
結(jié)論
InnoDB 在RC（READ COMMITTED）隔離級別中轻猖，只會在對應(yīng)的索引/行記錄上加Record Lock帆吻，而不會加Gap鎖，原因也很簡單咙边，因為該隔離級別是允許存在幻讀問題的猜煮。
在RR級別下的加鎖方式稱之為Next-Key Locks，其實就是上述Record Locks和Gap Locks的結(jié)合败许。比如Gap Lock為(10,20) ,record lock為20王带，結(jié)合的Next-Key lock 為：(10, 20]。
分析Next-Key Locks其實就是要分析Record Locks和Gap Locks市殷。MySQL InnoDB的可重復(fù)讀并不保證避免幻讀愕撰，需要應(yīng)用使用加鎖讀來保證。而這個加鎖讀使用到的機制就是next-key locks被丧。
如果使用普通的讀盟戏，會得到一致性的結(jié)果，如果使用了加鎖的讀甥桂，就會讀到“最新的”“提交”讀的結(jié)果柿究。本身，可重復(fù)讀和提交讀是矛盾的黄选。在同一個事務(wù)里蝇摸，如果保證了可重復(fù)讀婶肩，
就會看不到其他事務(wù)的提交，違背了提交讀貌夕；如果保證了提交讀律歼，就會導(dǎo)致前后兩次讀到的結(jié)果不一致，違背了可重復(fù)讀啡专∠栈伲可以這么講，InnoDB提供了這樣的機制们童，在默認(rèn)的可重復(fù)讀的隔離級別里畔况，可以使用加鎖讀去查詢最新的數(shù)據(jù)。
