我們都知道事務的幾種性質，數據庫為了維護這些性質，尤其是一致性和隔離性，一般使用加鎖這種方式。同時數據庫又是個高并發的應用，同一時間會有大量的并發訪問，如果加鎖過度，會極大的降低并發處理能力。所以對于加鎖的處理，可以說就是數據庫對于事務處理的精髓所在。

#一次封鎖or兩段鎖？

因為有大量的并發訪問，為了預防死鎖，一般應用中推薦使用一次封鎖法，就是在方法的開始階段，已經預先知道會用到哪些數據，然后全部鎖住，在方法運行之后，再全部解鎖。這種方式可以有效的避免循環死鎖，但在數據庫中卻不適用，因為在事務開始階段，數據庫并不知道會用到哪些數據。

數據庫遵循的是兩段鎖協議，將事務分成兩個階段，加鎖階段和解鎖階段（所以叫兩段鎖）

加鎖階段：在該階段可以進行加鎖操作。在對任何數據進行讀操作之前要申請并獲得S鎖（共享鎖，其它事務可以繼續加共享鎖，但不能加排它鎖），在進行寫操作之前要申請并獲得X鎖（排它鎖，其它事務不能再獲得任何鎖）。加鎖不成功，則事務進入等待狀態，直到加鎖成功才繼續執行。

解鎖階段：當事務釋放了一個封鎖以后，事務進入解鎖階段，在該階段只能進行解鎖操作不能再進行加鎖操作。

這種方式雖然無法避免死鎖，但是兩段鎖協議可以保證事務的并發調度是串行化（串行化很重要，尤其是在數據恢復和備份的時候）的。

#事務中的加鎖方式

##事務的四種隔離級別

在數據庫操作中，為了有效保證并發讀取數據的正確性，提出的事務隔離級別。我們的數據庫鎖，也是為了構建這些隔離級別存在的。

未提交讀(Read Uncommitted)：允許臟讀，也就是可能讀取到其他會話中未提交事務修改的數據

提交讀(Read Committed)：只能讀取到已經提交的數據。Oracle等多數數據庫默認都是該級別 (不重復讀)

可重復讀(Repeated Read)：可重復讀。在同一個事務內的查詢都是事務開始時刻一致的，InnoDB默認級別。在SQL標準中，該隔離級別消除了不可重復讀，但是還存在幻象讀

串行讀(Serializable)：完全串行化的讀，每次讀都需要獲得表級共享鎖，讀寫相互都會阻塞

Read Uncommitted這種級別，數據庫一般都不會用，而且任何操作都不會加鎖，這里就不討論了。

##MySQL中鎖的種類

MySQL中鎖的種類很多，有常見的表鎖和行鎖，也有新加入的Metadata Lock等等,表鎖是對一整張表加鎖，雖然可分為讀鎖和寫鎖，但畢竟是鎖住整張表，會導致并發能力下降，一般是做ddl處理時使用。

行鎖則是鎖住數據行，這種加鎖方法比較復雜，但是由于只鎖住有限的數據，對于其它數據不加限制，所以并發能力強，MySQL一般都是用行鎖來處理并發事務。這里主要討論的也就是行鎖。

###Read Committed（讀取提交內容）

在RC級別中，數據的讀取都是不加鎖的，但是數據的寫入、修改和刪除是需要加鎖的。效果如下

由于MySQL的InnoDB默認是使用的RR級別，所以我們先要將該session開啟成RC級別

為了防止并發過程中的修改沖突，事務A中MySQL給teacher_id=1的數據行加鎖，并一直不commit（釋放鎖），那么事務B也就一直拿不到該行鎖，wait直到超時。

這時我們要注意到，teacher_id是有索引的，如果是沒有索引的class_name呢？update class_teacher set teacher_id=3 where class_name = '初三一班';

那么MySQL會給整張表的所有數據行的加行鎖。這里聽起來有點不可思議，但是當sql運行的過程中，MySQL并不知道哪些數據行是 class_name = '初三一班'的（沒有索引嘛），如果一個條件無法通過索引快速過濾，存儲引擎層面就會將所有記錄加鎖后返回，再由MySQL Server層進行過濾。

但在實際使用過程當中，MySQL做了一些改進，在MySQL Server過濾條件，發現不滿足后，會調用unlock_row方法，把不滿足條件的記錄釋放鎖 (違背了二段鎖協議的約束)。這樣做，保證了最后只會持有滿足條件記錄上的鎖，但是每條記錄的加鎖操作還是不能省略的。可見即使是MySQL，為了效率也是會違反規范的。

這種情況同樣適用于MySQL的默認隔離級別RR。所以對一個數據量很大的表做批量修改的時候，如果無法使用相應的索引，MySQL Server過濾數據的的時候特別慢，就會出現雖然沒有修改某些行的數據，但是它們還是被鎖住了的現象。

###Repeaable Read（可重讀）

這是MySQL中InnoDB默認的隔離級別。我們姑且分“讀”和“寫”兩個模塊來講解。

####讀

讀就是可重讀，可重讀這個概念是一事務的多個實例在并發讀取數據時，會看到同樣的數據行，有點抽象，我們來看一下效果。

事務B修改id=1的數據提交之后，事務A同樣的查詢，后一次和前一次的結果不一樣，這就是不可重讀（重新讀取產生的結果不一樣）。這就很可能帶來一些問題，那么我們來看看在RR級別中MySQL的表現：

我們注意到，當teacher_id=1時，事務A先做了一次讀取，事務B中間修改了id=1的數據，并commit之后，事務A第二次讀到的數據和第一次完全相同。所以說它是可重讀的。那么MySQL是怎么做到的呢？這里姑且賣個關子，我們往下看。

####不可重復讀和幻讀的區別####

很多人容易搞混不可重復讀和幻讀，確實這兩者有些相似。但不可重復讀重點在于update和delete，而幻讀的重點在于insert。

如果使用鎖機制來實現這兩種隔離級別，在可重復讀中，該sql第一次讀取到數據后，就將這些數據加鎖，其它事務無法修改這些數據，就可以實現可重復讀了。但這種方法卻無法鎖住insert的數據，所以當事務A先前讀取了數據，或者修改了全部數據，事務B還是可以insert數據提交，這時事務A就會發現莫名其妙多了一條之前沒有的數據，這就是幻讀，不能通過行鎖來避免。需要Serializable隔離級別 ，讀用讀鎖，寫用寫鎖，讀鎖和寫鎖互斥，這么做可以有效的避免幻讀、不可重復讀、臟讀等問題，但會極大的降低數據庫的并發能力。

所以說不可重復讀和幻讀最大的區別，就在于如何通過鎖機制來解決他們產生的問題。

上文說的，是使用悲觀鎖機制來處理這兩種問題，但是MySQL、ORACLE、PostgreSQL等成熟的數據庫，出于性能考慮，都是使用了以樂觀鎖為理論基礎的MVCC（多版本并發控制）來避免這兩種問題。

####悲觀鎖和樂觀鎖####

悲觀鎖

正如其名，它指的是對數據被外界（包括本系統當前的其他事務，以及來自外部系統的事務處理）修改持保守態度，因此，在整個數據處理過程中，將數據處于鎖定狀態。悲觀鎖的實現，往往依靠數據庫提供的鎖機制（也只有數據庫層提供的鎖機制才能真正保證數據訪問的排他性，否則，即使在本系統中實現了加鎖機制，也無法保證外部系統不會修改數據）。

在悲觀鎖的情況下，為了保證事務的隔離性，就需要一致性鎖定讀。讀取數據時給加鎖，其它事務無法修改這些數據。修改刪除數據時也要加鎖，其它事務無法讀取這些數據。

樂觀鎖

相對悲觀鎖而言，樂觀鎖機制采取了更加寬松的加鎖機制。悲觀鎖大多數情況下依靠數據庫的鎖機制實現，以保證操作最大程度的獨占性。但隨之而來的就是數據庫性能的大量開銷，特別是對長事務而言，這樣的開銷往往無法承受。

而樂觀鎖機制在一定程度上解決了這個問題。樂觀鎖，大多是基于數據版本（Version）記錄機制實現。何謂數據版本？即為數據增加一個版本標識，在基于數據庫表的版本解決方案中，一般是通過為數據庫表增加一個 “version” 字段來實現。讀取出數據時，將此版本號一同讀出，之后更新時，對此版本號加一。此時，將提交數據的版本數據與數據庫表對應記錄的當前版本信息進行比對，如果提交的數據版本號大于數據庫表當前版本號，則予以更新，否則認為是過期數據。

要說明的是，MVCC的實現沒有固定的規范，每個數據庫都會有不同的實現方式，這里討論的是InnoDB的MVCC。

####MVCC在MySQL的InnoDB中的實現

在InnoDB中，會在每行數據后添加兩個額外的隱藏的值來實現MVCC，這兩個值一個記錄這行數據何時被創建，另外一個記錄這行數據何時過期（或者被刪除）。 在實際操作中，存儲的并不是時間，而是事務的版本號，每開啟一個新事務，事務的版本號就會遞增。 在可重讀Repeatable reads事務隔離級別下：

SELECT時，讀取創建版本號<=當前事務版本號，刪除版本號為空或>當前事務版本號。

INSERT時，保存當前事務版本號為行的創建版本號

DELETE時，保存當前事務版本號為行的刪除版本號

UPDATE時，插入一條新紀錄，保存當前事務版本號為行創建版本號，同時保存當前事務版本號到原來刪除的行

通過MVCC，雖然每行記錄都需要額外的存儲空間，更多的行檢查工作以及一些額外的維護工作，但可以減少鎖的使用，大多數讀操作都不用加鎖，讀數據操作很簡單，性能很好，并且也能保證只會讀取到符合標準的行，也只鎖住必要行。

我們不管從數據庫方面的教課書中學到，還是從網絡上看到，大都是上文中事務的四種隔離級別這一模塊列出的意思，RR級別是可重復讀的，但無法解決幻讀，而只有在Serializable級別才能解決幻讀。于是我就加了一個事務C來展示效果。在事務C中添加了一條teacher_id=1的數據commit，RR級別中應該會有幻讀現象，事務A在查詢teacher_id=1的數據時會讀到事務C新加的數據。但是測試后發現，在MySQL中是不存在這種情況的，在事務C提交后，事務A還是不會讀到這條數據。可見在MySQL的RR級別中，是解決了幻讀的讀問題的。參見下圖

讀問題解決了，根據MVCC的定義，并發提交數據時會出現沖突，那么沖突時如何解決呢？我們再來看看InnoDB中RR級別對于寫數據的處理。

####“讀”與“讀”的區別

可能有讀者會疑惑，事務的隔離級別其實都是對于讀數據的定義，但到了這里，就被拆成了讀和寫兩個模塊來講解。這主要是因為MySQL中的讀，和事務隔離級別中的讀，是不一樣的。

我們且看，在RR級別中，通過MVCC機制，雖然讓數據變得可重復讀，但我們讀到的數據可能是歷史數據，是不及時的數據，不是數據庫當前的數據！這在一些對于數據的時效特別敏感的業務中，就很可能出問題。

對于這種讀取歷史數據的方式，我們叫它快照讀(snapshot read)，而讀取數據庫當前版本數據的方式，叫當前讀 (current read)。很顯然，在MVCC中：

快照讀：就是select

select * from table ....;

當前讀：特殊的讀操作，插入/更新/刪除操作，屬于當前讀，處理的都是當前的數據，需要加鎖。

select * from table where ? lock in share mode;

select * from table where ? for update;

insert;

update ;

delete;

事務的隔離級別實際上都是定義了當前讀的級別，MySQL為了減少鎖處理（包括等待其它鎖）的時間，提升并發能力，引入了快照讀的概念，使得select不用加鎖。而update、insert這些“當前讀”，就需要另外的模塊來解決了。

###寫（"當前讀"）

事務的隔離級別中雖然只定義了讀數據的要求，實際上這也可以說是寫數據的要求。上文的“讀”，實際是講的快照讀；而這里說的“寫”就是當前讀了。

為了解決當前讀中的幻讀問題，MySQL事務使用了Next-Key鎖。

####Next-Key鎖

Next-Key鎖是行鎖和GAP（間隙鎖）的合并，行鎖上文已經介紹了，接下來說下GAP間隙鎖。

行鎖可以防止不同事務版本的數據修改提交時造成數據沖突的情況。但如何避免別的事務插入數據就成了問題。我們可以看看RR級別和RC級別的對比

RC級別：

RR級別：

通過對比我們可以發現，在RC級別中，事務A修改了所有teacher_id=30的數據，但是當事務B insert進新數據后，事務A發現莫名其妙多了一行teacher_id=30的數據，而且沒有被之前的update語句所修改，這就是“當前讀”的幻讀。

RR級別中，事務A在update后加鎖，事務B無法插入新數據，這樣事務A在update前后讀的數據保持一致，避免了幻讀。這個鎖，就是Gap鎖。

接下來將選擇幾個有代表性的例子，來詳細分析MySQL的加鎖處理。當然，還是從最簡單的例子說起。下面兩條簡單的SQL，他們加什么鎖？

SQL1：select * from t1 where id = 10;

SQL2：delete from t1 where id = 10;

針對這個問題，該怎么回答？能想象到的一個答案是：

SQL1：不加鎖。因為MySQL是使用多版本并發控制的，讀不加鎖。

SQL2：對id = 10的記錄加寫鎖 (走主鍵索引)。

這個答案對嗎？說不上來。即可能是正確的，也有可能是錯誤的，已知條件不足，這個問題沒有答案。必須還要知道以下的一些前提，前提不同，能給出的答案也就不同。要回答這個問題，還缺少哪些前提條件？

前提一：id列是不是主鍵？

前提二：當前系統的隔離級別是什么？

前提三：id列如果不是主鍵，那么id列上有索引嗎？

前提四：id列上如果有二級索引，那么這個索引是唯一索引嗎？

前提五：兩個SQL的執行計劃是什么？索引掃描？全表掃描？

下面將這些問題的答案進行組合，然后按照從易到難的順序，逐個分析每種組合下，對應的SQL會加哪些鎖？

注：對下面的這些組合，做一個前提假設，也就是有索引時，執行計劃一定會選擇使用索引進行過濾(索引掃描)。但實際情況會復雜很多，真正的執行計劃，還是需要根據MySQL輸出的為準。

組合一：id列是主鍵，RC隔離級別

組合二：id列是二級唯一索引，RC隔離級別

組合三：id列是二級非唯一索引，RC隔離級別

組合四：id列上沒有索引，RC隔離級別

組合五：id列是主鍵，RR隔離級別

組合六：id列是二級唯一索引，RR隔離級別

組合七：id列是二級非唯一索引，RR隔離級別

組合八：id列上沒有索引，RR隔離級別

組合九：Serializable隔離級別

注：在前面八種組合下，也就是RC，RR隔離級別下，SQL1：select操作均不加鎖，采用的是快照讀，因此在下面的討論中就忽略了，主要討論SQL2：delete操作的加鎖。

組合一：id主鍵+RC

這個組合，是最簡單，最容易分析的組合。id是主鍵，Read Committed隔離級別，給定SQL：delete from t1 where id = 10; 只需要將主鍵上，id = 10的記錄加上X鎖即可。如下圖所示：

結論：id是主鍵時，此SQL只需要在id=10這條記錄上加X鎖即可。

組合二：id唯一索引+RC

這個組合，id不是主鍵，而是一個Unique的二級索引鍵值。那么在RC隔離級別下，delete from t1 where id = 10; 需要加什么鎖呢？見下圖：

此組合中，id是unique索引，而主鍵是name列。此時，加鎖的情況由于組合一有所不同。由于id是unique索引，因此delete語句會選擇走id列的索引進行where條件的過濾，在找到id=10的記錄后，首先會將unique索引上的id=10索引記錄加上X鎖，同時，會根據讀取到的name列，回主鍵索引(聚簇索引)，然后將聚簇索引上的name = ‘d’ 對應的主鍵索引項加X鎖。為什么聚簇索引上的記錄也要加鎖？試想一下，如果并發的一個SQL，是通過主鍵索引來更新：update t1 set id = 100 where name = ‘d’; 此時，如果delete語句沒有將主鍵索引上的記錄加鎖，那么并發的update就會感知不到delete語句的存在，違背了同一記錄上的更新/刪除需要串行執行的約束。

結論：若id列是unique列，其上有unique索引。那么SQL需要加兩個X鎖，一個對應于id unique索引上的id = 10的記錄，另一把鎖對應于聚簇索引上的[name=’d’,id=10]的記錄。

組合三：id非唯一索引+RC

相對于組合一、二，組合三又發生了變化，隔離級別仍舊是RC不變，但是id列上的約束又降低了，id列不再唯一，只有一個普通的索引。假設delete from t1 where id = 10; 語句，仍舊選擇id列上的索引進行過濾where條件，那么此時會持有哪些鎖？同樣見下圖：

根據此圖，可以看到，首先，id列索引上，滿足id = 10查詢條件的記錄，均已加鎖。同時，這些記錄對應的主鍵索引上的記錄也都加上了鎖。與組合二唯一的區別在于，組合二最多只有一個滿足等值查詢的記錄，而組合三會將所有滿足查詢條件的記錄都加鎖。

結論：若id列上有非唯一索引，那么對應的所有滿足SQL查詢條件的記錄，都會被加鎖。同時，這些記錄在主鍵索引上的記錄，也會被加鎖。

組合四：id無索引+RC

相對于前面三個組合，這是一個比較特殊的情況。id列上沒有索引，where id = 10;這個過濾條件，沒法通過索引進行過濾，那么只能走全表掃描做過濾。對應于這個組合，SQL會加什么鎖？或者是換句話說，全表掃描時，會加什么鎖？這個答案也有很多：有人說會在表上加X鎖；有人說會將聚簇索引上，選擇出來的id = 10;的記錄加上X鎖。那么實際情況呢？請看下圖：

由于id列上沒有索引，因此只能走聚簇索引，進行全部掃描。從圖中可以看到，滿足刪除條件的記錄有兩條，但是，聚簇索引上所有的記錄，都被加上了X鎖。無論記錄是否滿足條件，全部被加上X鎖。既不是加表鎖，也不是在滿足條件的記錄上加行鎖。

有人可能會問？為什么不是只在滿足條件的記錄上加鎖呢？這是由于MySQL的實現決定的。如果一個條件無法通過索引快速過濾，那么存儲引擎層面就會將所有記錄加鎖后返回，然后由MySQL Server層進行過濾。因此也就把所有的記錄，都鎖上了。

注：在實際的實現中，MySQL有一些改進，在MySQL Server過濾條件，發現不滿足后，會調用unlock_row方法，把不滿足條件的記錄放鎖 (違背了2PL的約束)。這樣做，保證了最后只會持有滿足條件記錄上的鎖，但是每條記錄的加鎖操作還是不能省略的。

結論：若id列上沒有索引，SQL會走聚簇索引的全掃描進行過濾，由于過濾是由MySQL Server層面進行的。因此每條記錄，無論是否滿足條件，都會被加上X鎖。但是，為了效率考量，MySQL做了優化，對于不滿足條件的記錄，會在判斷后放鎖，最終持有的，是滿足條件的記錄上的鎖，但是不滿足條件的記錄上的加鎖/放鎖動作不會省略。同時，優化也違背了2PL的約束。

組合五：id主鍵+RR

上面的四個組合，都是在Read Committed隔離級別下的加鎖行為，接下來的四個組合，是在Repeatable Read隔離級別下的加鎖行為。

組合五，id列是主鍵列，Repeatable Read隔離級別，針對delete from t1 where id = 10; 這條SQL，加鎖與組合一：[id主鍵，Read Committed]一致。

組合六：id唯一索引+RR

與組合五類似，組合六的加鎖，與組合二：[id唯一索引，Read Committed]一致。兩個X鎖，id唯一索引滿足條件的記錄上一個，對應的聚簇索引上的記錄一個。

組合七：id非唯一索引+RR

還記得前面提到的MySQL的四種隔離級別的區別嗎？RC隔離級別允許幻讀，而RR隔離級別，不允許存在幻讀。但是在組合五、組合六中，加鎖行為又是與RC下的加鎖行為完全一致。那么RR隔離級別下，如何防止幻讀呢？問題的答案，就在組合七中揭曉。

組合七，Repeatable Read隔離級別，id上有一個非唯一索引，執行delete from t1 where id = 10; 假設選擇id列上的索引進行條件過濾，最后的加鎖行為，是怎么樣的呢？同樣看下面這幅圖：

此圖，相對于組合三：[id列上非唯一鎖，Read Committed]看似相同，其實卻有很大的區別。最大的區別在于，這幅圖中多了一個GAP鎖，而且GAP鎖看起來也不是加在記錄上的，倒像是加載兩條記錄之間的位置，GAP鎖有何用？

其實這個多出來的GAP鎖，就是RR隔離級別，相對于RC隔離級別，不會出現幻讀的關鍵。確實，GAP鎖鎖住的位置，也不是記錄本身，而是兩條記錄之間的GAP。所謂幻讀，就是同一個事務，連續做兩次當前讀 (例如：select * from t1 where id = 10 for update;)，那么這兩次當前讀返回的是完全相同的記錄 (記錄數量一致，記錄本身也一致)，第二次的當前讀，不會比第一次返回更多的記錄 (幻象)。

如何保證兩次當前讀返回一致的記錄，那就需要在第一次當前讀與第二次當前讀之間，其他的事務不會插入新的滿足條件的記錄并提交。為了實現這個功能，GAP鎖應運而生。

如圖中所示，有哪些位置可以插入新的滿足條件的項(id = 10)，考慮到B+樹索引的有序性，滿足條件的項一定是連續存放的。記錄[6,c]之前，不會插入id=10的記錄；[6,c]與[10,b]間可以插入[10, aa]；[10,b]與[10,d]間，可以插入新的[10,bb],[10,c]等；[10,d]與[11,f]間可以插入滿足條件的[10,e],[10,z]等；而[11,f]之后也不會插入滿足條件的記錄。因此，為了保證[6,c]與[10,b]間，[10,b]與[10,d]間，[10,d]與[11,f]不會插入新的滿足條件的記錄，MySQL選擇了用GAP鎖，將這三個GAP給鎖起來。

Insert操作，如insert [10,aa]，首先會定位到[6,c]與[10,b]間，然后在插入前，會檢查這個GAP是否已經被鎖上，如果被鎖上，則Insert不能插入記錄。因此，通過第一遍的當前讀，不僅將滿足條件的記錄鎖上 (X鎖)，與組合三類似。同時還是增加3把GAP鎖，將可能插入滿足條件記錄的3個GAP給鎖上，保證后續的Insert不能插入新的id=10的記錄，也就杜絕了同一事務的第二次當前讀，出現幻象的情況。

有心的朋友看到這兒，可以會問：既然防止幻讀，需要靠GAP鎖的保護，為什么組合五、組合六，也是RR隔離級別，卻不需要加GAP鎖呢？

首先，這是一個好問題。其次，回答這個問題，也很簡單。GAP鎖的目的，是為了防止同一事務的兩次當前讀，出現幻讀的情況。而組合五，id是主鍵；組合六，id是unique鍵，都能夠保證唯一性。一個等值查詢，最多只能返回一條記錄，而且新的相同取值的記錄，一定不會在新插入進來，因此也就避免了GAP鎖的使用。

結論：Repeatable Read隔離級別下，id列上有一個非唯一索引，對應SQL：delete from t1 where id = 10; 首先，通過id索引定位到第一條滿足查詢條件的記錄，加記錄上的X鎖，加GAP上的GAP鎖，然后加主鍵聚簇索引上的記錄X鎖，然后返回；然后讀取下一條，重復進行。直至進行到第一條不滿足條件的記錄[11,f]，此時，不需要加記錄X鎖，但是仍舊需要加GAP鎖，最后返回結束。

組合八：id無索引+RR

組合八，Repeatable Read隔離級別下的最后一種情況，id列上沒有索引。此時SQL：delete from t1 where id = 10; 沒有其他的路徑可以選擇，只能進行全表掃描。最終的加鎖情況，如下圖所示：

如圖，這是一個很恐怖的現象。首先，聚簇索引上的所有記錄，都被加上了X鎖。其次，聚簇索引每條記錄間的間隙(GAP)，也同時被加上了GAP鎖。這個示例表，只有6條記錄，一共需要6個記錄鎖，7個GAP鎖。試想，如果表上有1000萬條記錄呢？

在這種情況下，這個表上，除了不加鎖的快照度，其他任何加鎖的并發SQL，均不能執行，不能更新，不能刪除，不能插入，全表被鎖死。

當然，跟組合四：[id無索引, Read Committed]類似，這個情況下，MySQL也做了一些優化，就是所謂的semi-consistent read。semi-consistent read開啟的情況下，對于不滿足查詢條件的記錄，MySQL會提前放鎖。針對上面的這個用例，就是除了記錄[d,10]，[g,10]之外，所有的記錄鎖都會被釋放，同時不加GAP鎖。

結論：在Repeatable Read隔離級別下，如果進行全表掃描的當前讀，那么會鎖上表中的所有記錄，同時會鎖上聚簇索引內的所有GAP，杜絕所有的并發 更新/刪除/插入 操作。當然，也可以通過觸發semi-consistent read，來緩解加鎖開銷與并發影響，但是semi-consistent read本身也會帶來其他問題，不建議使用。

組合九：Serializable

針對前面提到的簡單的SQL，最后一個情況：Serializable隔離級別。對于SQL2：delete from t1 where id = 10; 來說，Serializable隔離級別與Repeatable Read隔離級別完全一致，因此不做介紹。

Serializable隔離級別，影響的是SQL1：select * from t1 where id = 10; 這條SQL，在RC，RR隔離級別下，都是快照讀，不加鎖。但是在Serializable隔離級別，SQL1會加讀鎖，也就是說快照讀不復存在，MVCC并發控制降級為Lock-Based CC。

結論：在MySQL/InnoDB中，所謂的讀不加鎖，并不適用于所有的情況，而是隔離級別相關的。Serializable隔離級別，讀不加鎖就不再成立，所有的讀操作，都是當前讀。

一條復雜的SQL

寫到這里，其實MySQL的加鎖實現也已經介紹的八八九九。只要將本文上面的分析思路，大部分的SQL，都能分析出其會加哪些鎖。而這里，再來看一個稍微復雜點的SQL，用于說明MySQL加鎖的另外一個邏輯。SQL用例如下：

假設SQL走的是idx_t1_pu索引。

Index key：pubtime > 1 and puptime < 20。此條件，用于確定SQL在idx_t1_pu索引上的查詢范圍。

Index Filter：userid = ‘hdc’ 。此條件，可以在idx_t1_pu索引上進行過濾，但不屬于Index Key。

Table Filter：comment is not NULL。此條件，在idx_t1_pu索引上無法過濾，只能在聚簇索引上過濾。

在分析出SQL where條件的構成之后，再來看看這條SQL的加鎖情況 (RR隔離級別)，如下圖所示：

從圖中可以看出，在Repeatable Read隔離級別下，由Index Key所確定的范圍，被加上了GAP鎖；Index Filter鎖給定的條件 (userid = ‘hdc’)何時過濾，視MySQL的版本而定，在MySQL 5.6版本之前，不支持Index Condition Pushdown(ICP)，因此Index Filter在MySQL Server層過濾，在5.6后支持了Index Condition Pushdown，則在index上過濾。若不支持ICP，不滿足Index Filter的記錄，也需要加上記錄X鎖，若支持ICP，則不滿足Index Filter的記錄，無需加記錄X鎖 (圖中，用紅色箭頭標出的X鎖，是否要加，視是否支持ICP而定)；而Table Filter對應的過濾條件，則在聚簇索引中讀取后，在MySQL Server層面過濾，因此聚簇索引上也需要X鎖。最后，選取出了一條滿足條件的記錄[8,hdc,d,5,good]，但是加鎖的數量，要遠遠大于滿足條件的記錄數量。

結論：在Repeatable Read隔離級別下，針對一個復雜的SQL，首先需要提取其where條件。Index Key確定的范圍，需要加上GAP鎖；Index Filter過濾條件，視MySQL版本是否支持ICP，若支持ICP，則不滿足Index Filter的記錄，不加X鎖，否則需要X鎖；Table Filter過濾條件，無論是否滿足，都需要加X鎖。

死鎖原理與分析

本文前面的部分，基本上已經涵蓋了MySQL/InnoDB所有的加鎖規則。深入理解MySQL如何加鎖，有兩個比較重要的作用：

可以根據MySQL的加鎖規則，寫出不會發生死鎖的SQL；

可以根據MySQL的加鎖規則，定位出線上產生死鎖的原因；

下面，來看看兩個死鎖的例子(一個是兩個Session的兩條SQL產生死鎖；另一個是兩個Session的一條SQL，產生死鎖)：

上面的兩個死鎖用例。第一個非常好理解，也是最常見的死鎖，每個事務執行兩條SQL，分別持有了一把鎖，然后加另一把鎖，產生死鎖。

第二個用例，雖然每個Session都只有一條語句，仍舊會產生死鎖。要分析這個死鎖，首先必須用到本文前面提到的MySQL加鎖的規則。針對Session 1，從name索引出發，讀到的[hdc, 1]，[hdc, 6]均滿足條件，不僅會加name索引上的記錄X鎖，而且會加聚簇索引上的記錄X鎖，加鎖順序為先[1,hdc,100]，后[6,hdc,10]。而Session 2，從pubtime索引出發，[10,6],[100,1]均滿足過濾條件，同樣也會加聚簇索引上的記錄X鎖，加鎖順序為[6,hdc,10]，后[1,hdc,100]。發現沒有，跟Session 1的加鎖順序正好相反，如果兩個Session恰好都持有了第一把鎖，請求加第二把鎖，死鎖就發生了。

結論：死鎖的發生與否，并不在于事務中有多少條SQL語句，死鎖的關鍵在于：兩個(或以上)的Session加鎖的順序不一致。而使用本文上面提到的，分析MySQL每條SQL語句的加鎖規則，分析出每條語句的加鎖順序，然后檢查多個并發SQL間是否存在以相反的順序加鎖的情況，就可以分析出各種潛在的死鎖情況，也可以分析出線上死鎖發生的原因。