一篇很好的文章，mark！
寫在前面：
隔離級別：Isolation Level，也是RDBMS的一個關鍵特性。相信對數(shù)據(jù)庫有所了解的朋友，對于4種隔離級別：Read Uncommited，Read Committed，Repeatable Read，Serializable，都有了深入的認識。本文不打算討論數(shù)據(jù)庫理論中，是如何定義這4種隔離級別的含義的，而是跟大家介紹一下MySQL/InnoDB是如何定義這4種隔離級別的。
MySQL/InnoDB定義的4種隔離級別：
-
Read Uncommited
可以讀取未提交記錄。此隔離級別，不會使用，忽略。 -
Read Committed (RC)
快照讀忽略，本文不考慮。
針對當前讀，RC隔離級別保證對讀取到的記錄加鎖 (記錄鎖)，存在幻讀現(xiàn)象。 -
Repeatable Read (RR)
快照讀忽略，本文不考慮。
針對當前讀，RR隔離級別保證對讀取到的記錄加鎖 (記錄鎖)，同時保證對讀取的范圍加鎖，新的滿足查詢條件的記錄不能夠插入 (間隙鎖)，不存在幻讀現(xiàn)象。 -
Serializable
從MVCC并發(fā)控制退化為基于鎖的并發(fā)控制。不區(qū)別快照讀與當前讀，所有的讀操作均為當前讀，讀加讀鎖 (S鎖)，寫加寫鎖 (X鎖)。
Serializable隔離級別下，讀寫沖突，因此并發(fā)度急劇下降，在MySQL/InnoDB下不建議使用。
在介紹完一些背景知識之后，本文接下來將選擇幾個有代表性的例子，來詳細分析MySQL的加鎖處理。當然，還是從最簡單的例子說起。經(jīng)常有朋友發(fā)給我一個SQL，然后問我，這個SQL加什么鎖？就如同下面兩條簡單的SQL，他們加什么鎖？
SQL1：select * from t1 where id = 10;
SQL2：delete from t1 where id = 10;
針對這個問題，該怎么回答？我能想象到的一個答案是：
SQL1：不加鎖。因為MySQL是使用多版本并發(fā)控制的，讀不加鎖。
SQL2：對id = 10的記錄加寫鎖 (走主鍵索引)。
這個答案對嗎？說不上來。即可能是正確的，也有可能是錯誤的，已知條件不足，這個問題沒有答案。如果讓我來回答這個問題，我必須還要知道以下的一些前提，前提不同，我能給出的答案也就不同。要回答這個問題，還缺少哪些前提條件？
前提一：id列是不是主鍵？
前提二：當前系統(tǒng)的隔離級別是什么？
前提三：id列如果不是主鍵，那么id列上有索引嗎？
前提四：id列上如果有二級索引，那么這個索引是唯一索引嗎？
前提五：兩個SQL的執(zhí)行計劃是什么？索引掃描？全表掃描？
沒有這些前提，直接就給定一條SQL，然后問這個SQL會加什么鎖，都是很業(yè)余的表現(xiàn)。而當這些問題有了明確的答案之后，給定的SQL會加什么鎖，也就一目了然。下面，我將這些問題的答案進行組合，然后按照從易到難的順序，逐個分析每種組合下，對應的SQL會加哪些鎖？
下面的這些組合，我做了一個前提假設，也就是有索引時，執(zhí)行計劃一定會選擇使用索引進行過濾 (索引掃描)。但實際情況會復雜很多，真正的執(zhí)行計劃，還是需要根據(jù)MySQL輸出的為準。
組合一：id列是主鍵，RC隔離級別
組合二：id列是二級唯一索引，RC隔離級別
組合三：id列是二級非唯一索引，RC隔離級別
組合四：id列上沒有索引，RC隔離級別
組合五：id列是主鍵，RR隔離級別
組合六：id列是二級唯一索引，RR隔離級別
組合七：id列是二級非唯一索引，RR隔離級別
組合八：id列上沒有索引，RR隔離級別
組合九：Serializable隔離級別
組合一：id主鍵+RC
這個組合，是最簡單，最容易分析的組合。id是主鍵，Read Committed隔離級別，給定SQL：delete from t1 where id = 10; 只需要將主鍵上，id = 10的記錄加上X鎖即可。如下圖所示：
結(jié)論：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鎖，同時，會根據(jù)讀取到的name列，回主鍵索引(聚簇索引)，然后將聚簇索引上的name = ‘d’ 對應的主鍵索引項加X鎖。為什么聚簇索引上的記錄也要加鎖？試想一下，如果并發(fā)的一個SQL，是通過主鍵索引來更新：update t1 set id = 100 where name = ‘d’; 此時，如果delete語句沒有將主鍵索引上的記錄加鎖，那么并發(fā)的update就會感知不到delete語句的存在，違背了同一記錄上的更新/刪除需要串行執(zhí)行的約束。
結(jié)論：若id列是unique列，其上有unique索引。那么SQL需要加兩個X鎖，一個對應于id unique索引上的id = 10的記錄，另一把鎖對應于聚簇索引上的[name=’d’,id=10]的記錄。
組合三：id非唯一索引+RC
相對于組合一、二，組合三又發(fā)生了變化，隔離級別仍舊是RC不變，但是id列上的約束又降低了，id列不再唯一，只有一個普通的索引。假設delete from t1 where id = 10; 語句，仍舊選擇id列上的索引進行過濾where條件，那么此時會持有哪些鎖？同樣見下圖：
根據(jù)此圖，可以看到，首先，id列索引上，滿足id = 10查詢條件的記錄，均已加鎖。同時，這些記錄對應的主鍵索引上的記錄也都加上了鎖。與組合二唯一的區(qū)別在于，組合二最多只有一個滿足等值查詢的記錄，而組合三會將所有滿足查詢條件的記錄都加鎖。
結(jié)論：若id列上有非唯一索引，那么對應的所有滿足SQL查詢條件的記錄，都會被加鎖。同時，這些記錄在主鍵索引上的記錄，也會被加鎖。
組合四：id無索引+RC
相對于前面三個組合，這是一個比較特殊的情況。id列上沒有索引，where id = 10;這個過濾條件，沒法通過索引進行過濾，那么只能走全表掃描做過濾。對應于這個組合，SQL會加什么鎖？或者是換句話說，全表掃描時，會加什么鎖？這個答案也有很多：有人說會在表上加X鎖；有人說會將聚簇索引上，選擇出來的id = 10;的記錄加上X鎖。那么實際情況呢？請看下圖：
由于id列上沒有索引，因此只能走聚簇索引，進行全部掃描。從圖中可以看到，滿足刪除條件的記錄有兩條，但是，聚簇索引上所有的記錄，都被加上了X鎖。無論記錄是否滿足條件，全部被加上X鎖。既不是加表鎖，也不是在滿足條件的記錄上加行鎖。
有人可能會問？為什么不是只在滿足條件的記錄上加鎖呢？這是由于MySQL的實現(xiàn)決定的。如果一個條件無法通過索引快速過濾，那么存儲引擎層面就會將所有記錄加鎖后返回，然后由MySQL Server層進行過濾。因此也就把所有的記錄，都鎖上了。
注：在實際的實現(xiàn)中，MySQL有一些改進，在MySQL Server過濾條件，發(fā)現(xiàn)不滿足后，會調(diào)用unlock_row方法，把不滿足條件的記錄放鎖 (違背了2PL的約束)。這樣做，保證了最后只會持有滿足條件記錄上的鎖，但是每條記錄的加鎖操作還是不能省略的。
結(jié)論：若id列上沒有索引，SQL會走聚簇索引的全掃描進行過濾，由于過濾是由MySQL Server層面進行的。因此每條記錄，無論是否滿足條件，都會被加上X鎖。但是，為了效率考量，MySQL做了優(yōu)化，對于不滿足條件的記錄，會在判斷后放鎖，最終持有的，是滿足條件的記錄上的鎖，但是不滿足條件的記錄上的加鎖/放鎖動作不會省略。同時，優(yōu)化也違背了2PL的約束。
組合五：id主鍵+RR
上面的四個組合，都是在Read Committed隔離級別下的加鎖行為，接下來的四個組合，是在Repeatable Read隔離級別下的加鎖行為。
組合五，id列是主鍵列，Repeatable Read隔離級別，針對delete from t1 where id = 10; 這條SQL，加鎖與【組合一】一致。
組合六：id唯一索引+RR
與組合五類似，組合六的加鎖，與【組合二】一致。兩個X鎖，id唯一索引滿足條件的記錄上一個，對應的聚簇索引上的記錄一個。
組合七：id非唯一索引+RR
還記得前面提到的MySQL的四種隔離級別的區(qū)別嗎？RC隔離級別允許幻讀，而RR隔離級別，不允許存在幻讀。但是在組合五、組合六中，加鎖行為又是與RC下的加鎖行為完全一致。那么RR隔離級別下，如何防止幻讀呢？問題的答案，就在組合七中揭曉。
組合七，Repeatable Read隔離級別，id上有一個非唯一索引，執(zhí)行delete from t1 where id = 10; 假設選擇id列上的索引進行條件過濾，最后的加鎖行為，是怎么樣的呢？同樣看下面這幅圖：
此圖，相對于【組合三：id非唯一索引+RC】看似相同，其實卻有很大的區(qū)別。最大的區(qū)別在于，這幅圖中多了一個GAP鎖，而且GAP鎖看起來也不是加在記錄上的，倒像是加載兩條記錄之間的位置，GAP鎖有何用？
其實這個多出來的GAP鎖，就是RR隔離級別，相對于RC隔離級別，不會出現(xiàn)幻讀的關鍵。確實，GAP鎖鎖住的位置，也不是記錄本身，而是兩條記錄之間的GAP。所謂幻讀，就是同一個事務，連續(xù)做兩次當前讀 (例如：select * from t1 where id = 10 for update;)，那么這兩次當前讀返回的是完全相同的記錄 (記錄數(shù)量一致，記錄本身也一致)，第二次的當前讀，不會比第一次返回更多的記錄 (幻象)。
如何保證兩次當前讀返回一致的記錄，那就需要在第一次當前讀與第二次當前讀之間，其他的事務不會插入新的滿足條件的記錄并提交。為了實現(xiàn)這個功能，GAP鎖應運而生。
如圖中所示，有哪些位置可以插入新的滿足條件的項 (id = 10)，考慮到B+樹索引的有序性，滿足條件的項一定是連續(xù)存放的。記錄[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是否已經(jīng)被鎖上，如果被鎖上，則Insert不能插入記錄。因此，通過第一遍的當前讀，不僅將滿足條件的記錄鎖上 (X鎖)，與組合三類似。同時還是增加3把GAP鎖，將可能插入滿足條件記錄的3個GAP給鎖上，保證后續(xù)的Insert不能插入新的id=10的記錄，也就杜絕了同一事務的第二次當前讀，出現(xiàn)幻象的情況。
有心的朋友看到這兒，可以會問：既然防止幻讀，需要靠GAP鎖的保護，為什么組合五、組合六，也是RR隔離級別，卻不需要加GAP鎖呢？
首先，這是一個好問題。其次，回答這個問題，也很簡單。GAP鎖的目的，是為了防止同一事務的兩次當前讀，出現(xiàn)幻讀的情況。而組合五，id是主鍵；組合六，id是unique鍵，都能夠保證唯一性。一個等值查詢，最多只能返回一條記錄，而且新的相同取值的記錄，一定不會在新插入進來，因此也就避免了GAP鎖的使用。其實，針對此問題，還有一個更深入的問題：如果組合五、組合六下，針對SQL：select * from t1 where id = 10 for update; 第一次查詢，沒有找到滿足查詢條件的記錄，那么GAP鎖是否還能夠省略？此問題留給大家思考。
結(jié)論：Repeatable Read隔離級別下，id列上有一個非唯一索引，對應SQL：delete from t1 where id = 10; 首先，通過id索引定位到第一條滿足查詢條件的記錄，加記錄上的X鎖，加GAP上的GAP鎖，然后加主鍵聚簇索引上的記錄X鎖，然后返回；然后讀取下一條，重復進行。直至進行到第一條不滿足條件的記錄[11,f]，此時，不需要加記錄X鎖，但是仍舊需要加GAP鎖，最后返回結(jié)束。
組合八：id無索引+RR
組合八，Repeatable Read隔離級別下的最后一種情況，id列上沒有索引。此時SQL：delete from t1 where id = 10; 沒有其他的路徑可以選擇，只能進行全表掃描。最終的加鎖情況，如下圖所示：
如圖，這是一個很恐怖的現(xiàn)象。首先，聚簇索引上的所有記錄，都被加上了X鎖。其次，聚簇索引每條記錄間的間隙(GAP)，也同時被加上了GAP鎖。這個示例表，只有6條記錄，一共需要6個記錄鎖，7個GAP鎖。試想，如果表上有1000萬條記錄呢？
在這種情況下，這個表上，除了不加鎖的快照度，其他任何加鎖的并發(fā)SQL，均不能執(zhí)行，不能更新，不能刪除，不能插入，全表被鎖死。
組合九：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并發(fā)控制降級為Lock-Based CC。
結(jié)論：在MySQL/InnoDB中，所謂的讀不加鎖，并不適用于所有的情況，而是隔離級別相關的。Serializable隔離級別，讀不加鎖就不再成立，所有的讀操作，都是當前讀。
一條復雜的SQL
寫到這里，其實MySQL的加鎖實現(xiàn)也已經(jīng)介紹的八八九九。只要將本文上面的分析思路，大部分的SQL，都能分析出其會加哪些鎖。而這里，再來看一個稍微復雜點的SQL，用于說明MySQL加鎖的另外一個邏輯。SQL用例如下：
如圖中的SQL，會加什么鎖？假定在Repeatable Read隔離級別下 (Read Committed隔離級別下的加鎖情況，留給讀者分析。)，同時，假設SQL走的是idx_t1_pu索引。
在詳細分析這條SQL的加鎖情況前，還需要有一個知識儲備，那就是一個SQL中的where條件如何拆分？具體的介紹，建議閱讀我之前的一篇文章：SQL中的where條件，在數(shù)據(jù)庫中提取與應用淺析 。在這里，我直接給出分析后的結(jié)果：
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條件的構(gòu)成之后，再來看看這條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]，但是加鎖的數(shù)量，要遠遠大于滿足條件的記錄數(shù)量。
結(jié)論：在Repeatable Read隔離級別下，針對一個復雜的SQL，首先需要提取其where條件。Index Key確定的范圍，需要加上GAP鎖；Index Filter過濾條件，視MySQL版本是否支持ICP，若支持ICP，則不滿足Index Filter的記錄，不加X鎖，否則需要X鎖；Table Filter過濾條件，無論是否滿足，都需要加X鎖。
非常感謝網(wǎng)友的分享：
http://hedengcheng.com/?p=771
