背景 1
[1.1 MVCC：Snapshot Read vs Current Read 2]
[1.2 Cluster Index：聚簇索引 3]
[1.3 2PL：Two-Phase Locking 3]
[1.4 Isolation Level 4]
[2 一條簡單SQL的加鎖實(shí)現(xiàn)分析 5]
[2.1 組合一：id主鍵+RC 6]
[2.2 組合二：id唯一索引+RC 6]
[2.3 組合三：id非唯一索引+RC 7]
[2.4 組合四：id無索引+RC 8]
[2.5 組合五：id主鍵+RR 9]
[2.6 組合六：id唯一索引+RR 9]
[2.7 組合七：id非唯一索引+RR 9]
[2.8 組合八：id無索引+RR 11]
[2.9 組合九：Serializable 12]
[3一條復(fù)雜的SQL 12]
[4死鎖原理與分析 14]
[5總結(jié) 16]
-
背景
MySQL/InnoDB的加鎖分析哥牍，一直是一個比較困難的話題焰檩。我在工作過程中，經(jīng)常會有同事咨詢這方面的問題配乱。同時，微博上也經(jīng)常會收到MySQL鎖相關(guān)的私信局雄，讓我?guī)椭鉀Q一些死鎖的問題街州。本文，準(zhǔn)備就MySQL/InnoDB的加鎖問題柔纵，展開較為深入的分析與討論，主要是介紹一種思路锤躁，運(yùn)用此思路搁料，拿到任何一條SQL語句，都能完整的分析出這條語句會加什么鎖系羞？會有什么樣的使用風(fēng)險郭计？甚至是分析線上的一個死鎖場景，了解死鎖產(chǎn)生的原因椒振。
注：
MySQL是一個支持插件式存儲引擎的數(shù)據(jù)庫系統(tǒng)昭伸。本文下面的所有介紹，都是基于InnoDB存儲引擎澎迎，其他引擎的表現(xiàn)勋乾，會有較大的區(qū)別宋下。
-
MVCC：Snapshot Read vs Current Read
MySQL InnoDB存儲引擎嗡善，實(shí)現(xiàn)的是基于多版本的并發(fā)控制協(xié)議——MVCC (Multi-Version Concurrency Control) (注：與MVCC相對的辑莫，是基于鎖的并發(fā)控制，Lock-Based Concurrency Control)罩引。MVCC最大的好處各吨，相信也是耳熟能詳：讀不加鎖，讀寫不沖突袁铐。在讀多寫少的OLTP應(yīng)用中揭蜒，讀寫不沖突是非常重要的，極大的增加了系統(tǒng)的并發(fā)性能剔桨，這也是為什么現(xiàn)階段屉更，幾乎所有的RDBMS，都支持了MVCC洒缀。
在MVCC并發(fā)控制中瑰谜，讀操作可以分成兩類：快照讀 (snapshot read)與當(dāng)前讀 (current read)∈骷ǎ快照讀萨脑，讀取的是記錄的可見版本 (有可能是歷史版本)，不用加鎖饺饭。當(dāng)前讀渤早，讀取的是記錄的最新版本，并且瘫俊，當(dāng)前讀返回的記錄鹊杖，都會加上鎖，保證其他事務(wù)不會再并發(fā)修改這條記錄扛芽。
在一個支持MVCC并發(fā)控制的系統(tǒng)中骂蓖，哪些讀操作是快照讀？哪些操作又是當(dāng)前讀呢胸哥？以MySQL InnoDB為例：
-
快照讀：
簡單的select操作涯竟，屬于快照讀，不加鎖空厌。(當(dāng)然庐船，也有例外，下面會分析)
- select * from table where ?;
-
當(dāng)前讀：
特殊的讀操作嘲更，插入/更新/刪除操作筐钟，屬于當(dāng)前讀，需要加鎖赋朦。
select * from table where ? lock in share mode;
select * from table where ? for update;
insert into table values (…);
update table set ? where ?;
delete from table where ?;
所有以上的語句篓冲，都屬于當(dāng)前讀李破，讀取記錄的最新版本。并且壹将，讀取之后嗤攻，還需要保證其他并發(fā)事務(wù)不能修改當(dāng)前記錄，對讀取記錄加鎖诽俯。其中妇菱，除了第一條語句，對讀取記錄加S鎖 (共享鎖)外暴区，其他的操作闯团，都加的是X鎖 (排它鎖)。
為什么將 插入/更新/刪除 操作仙粱，都?xì)w為當(dāng)前讀房交？可以看看下面這個 更新 操作，在數(shù)據(jù)庫中的執(zhí)行流程：
從圖中伐割，可以看到候味，一個Update操作的具體流程。當(dāng)Update SQL被發(fā)給MySQL后口猜，MySQL Server會根據(jù)where條件负溪，讀取第一條滿足條件的記錄，然后InnoDB引擎會將第一條記錄返回济炎，并加鎖 (current read)川抡。待MySQL Server收到這條加鎖的記錄之后，會再發(fā)起一個Update請求须尚，更新這條記錄崖堤。一條記錄操作完成，再讀取下一條記錄耐床，直至沒有滿足條件的記錄為止密幔。因此，Update操作內(nèi)部撩轰，就包含了一個當(dāng)前讀胯甩。同理，Delete操作也一樣堪嫂。Insert操作會稍微有些不同偎箫，簡單來說，就是Insert操作可能會觸發(fā)Unique Key的沖突檢查皆串，也會進(jìn)行一個當(dāng)前讀淹办。
注：
根據(jù)上圖的交互，針對一條當(dāng)前讀的SQL語句恶复，InnoDB與MySQL Server的交互怜森，是一條一條進(jìn)行的速挑，因此，加鎖也是一條一條進(jìn)行的副硅。先對一條滿足條件的記錄加鎖姥宝，返回給MySQL Server，做一些DML操作想许；然后在讀取下一條加鎖伶授，直至讀取完畢。
-
Cluster Index：聚簇索引
InnoDB存儲引擎的數(shù)據(jù)組織方式流纹，是聚簇索引表：完整的記錄，存儲在主鍵索引中违诗，通過主鍵索引漱凝，就可以獲取記錄所有的列。關(guān)于聚簇索引表的組織方式诸迟，可以參考MySQL的官方文檔：Clustered and Secondary Indexes
茸炒。本文假設(shè)讀者對這個，已經(jīng)有了一定的認(rèn)識阵苇，就不再做具體的介紹壁公。接下來的部分，主鍵索引/聚簇索引 兩個名稱绅项，會有一些混用紊册，望讀者知曉。
-
2PL：Two-Phase Locking
傳統(tǒng)RDBMS加鎖的一個原則快耿，就是2PL (二階段鎖)：Two-Phase Locking囊陡。相對而言，2PL比較容易理解掀亥，說的是鎖操作分為兩個階段：加鎖階段與解鎖階段撞反，并且保證加鎖階段與解鎖階段不相交。下面搪花，仍舊以MySQL為例遏片，來簡單看看2PL在MySQL中的實(shí)現(xiàn)。
從上圖可以看出撮竿，2PL就是將加鎖/解鎖分為兩個完全不相交的階段吮便。加鎖階段：只加鎖，不放鎖倚聚。解鎖階段：只放鎖线衫，不加鎖。
-
Isolation Level
隔離級別：Isolation Level惑折，也是RDBMS的一個關(guān)鍵特性授账。相信對數(shù)據(jù)庫有所了解的朋友枯跑，對于4種隔離級別：Read Uncommited，Read Committed白热，Repeatable Read敛助，Serializable，都有了深入的認(rèn)識屋确。本文不打算討論數(shù)據(jù)庫理論中纳击，是如何定義這4種隔離級別的含義的，而是跟大家介紹一下MySQL/InnoDB是如何定義這4種隔離級別的攻臀。
MySQL/InnoDB定義的4種隔離級別：
-
Read Uncommited
可以讀取未提交記錄焕数。此隔離級別，不會使用刨啸，忽略堡赔。
-
Read Committed (RC)
快照讀忽略，本文不考慮设联。
針對當(dāng)前讀善已，RC隔離級別保證對讀取到的記錄加鎖 (記錄鎖)，存在幻讀現(xiàn)象离例。
-
Repeatable Read (RR)
快照讀忽略换团，本文不考慮。
針對當(dāng)前讀宫蛆，RR隔離級別保證對讀取到的記錄加鎖 (記錄鎖)艘包，同時保證對讀取的范圍加鎖，新的滿足查詢條件的記錄不能夠插入 (間隙鎖)洒扎，不存在幻讀現(xiàn)象辑甜。
-
Serializable
從MVCC并發(fā)控制退化為基于鎖的并發(fā)控制。不區(qū)別快照讀與當(dāng)前讀袍冷，所有的讀操作均為當(dāng)前讀磷醋，讀加讀鎖 (S鎖)，寫加寫鎖 (X鎖)胡诗。
Serializable隔離級別下邓线，讀寫沖突，因此并發(fā)度急劇下降煌恢，在MySQL/InnoDB下不建議使用骇陈。
-
一條簡單SQL的加鎖實(shí)現(xiàn)分析
在介紹完一些背景知識之后，本文接下來將選擇幾個有代表性的例子，來詳細(xì)分析MySQL的加鎖處理。當(dāng)然尤仍，還是從最簡單的例子說起遍烦。經(jīng)常有朋友發(fā)給我一個SQL婿崭，然后問我拨拓，這個SQL加什么鎖？就如同下面兩條簡單的SQL氓栈，他們加什么鎖渣磷？
SQL1：select * from t1 where id = 10;
SQL2：delete from t1 where id = 10;
針對這個問題，該怎么回答授瘦？我能想象到的一個答案是：
SQL1：不加鎖醋界。因?yàn)镸ySQL是使用多版本并發(fā)控制的，讀不加鎖提完。
SQL2：對id = 10的記錄加寫鎖 (走主鍵索引)形纺。
這個答案對嗎？說不上來氯葬。即可能是正確的挡篓，也有可能是錯誤的，已知條件不足帚称，這個問題沒有答案。如果讓我來回答這個問題秽澳，我必須還要知道以下的一些前提闯睹，前提不同，我能給出的答案也就不同担神。要回答這個問題楼吃，還缺少哪些前提條件？
-
前提一：
id列是不是主鍵妄讯？
-
前提二：
當(dāng)前系統(tǒng)的隔離級別是什么孩锡？
-
前提三：
id列如果不是主鍵，那么id列上有索引嗎亥贸？
-
前提四：
id列上如果有二級索引躬窜，那么這個索引是唯一索引嗎？
-
前提五：
兩個SQL的執(zhí)行計(jì)劃是什么炕置？索引掃描荣挨？全表掃描？
沒有這些前提朴摊，直接就給定一條SQL默垄，然后問這個SQL會加什么鎖，都是很業(yè)余的表現(xiàn)甚纲。而當(dāng)這些問題有了明確的答案之后口锭，給定的SQL會加什么鎖，也就一目了然介杆。下面鹃操，我將這些問題的答案進(jìn)行組合韭寸，然后按照從易到難的順序，逐個分析每種組合下组民，對應(yīng)的SQL會加哪些鎖棒仍？
注：
下面的這些組合，我做了一個前提假設(shè)臭胜，也就是有索引時莫其，執(zhí)行計(jì)劃一定會選擇使用索引進(jìn)行過濾 (索引掃描)。但實(shí)際情況會復(fù)雜很多耸三，真正的執(zhí)行計(jì)劃乱陡，還是需要根據(jù)MySQL輸出的為準(zhǔn)。
-
**組合一
：**id列是主鍵仪壮，RC隔離級別
-
**組合二
：**id列是二級唯一索引憨颠，RC隔離級別
-
**組合三
：**id列是二級非唯一索引，RC隔離級別
-
**組合四
：**id列上沒有索引积锅，RC隔離級別
-
**組合五
：**id列是主鍵爽彤，RR隔離級別
-
**組合六
：**id列是二級唯一索引，RR隔離級別
-
**組合七
：**id列是二級非唯一索引缚陷，RR隔離級別
-
**組合八
：**id列上沒有索引适篙，RR隔離級別
-
**組合九
：**Serializable隔離級別
排列組合還沒有列舉完全，但是看起來箫爷，已經(jīng)很多了嚷节。真的有必要這么復(fù)雜嗎？事實(shí)上虎锚，要分析加鎖硫痰，就是需要這么復(fù)雜。但是從另一個角度來說窜护，只要你選定了一種組合效斑，SQL需要加哪些鎖，其實(shí)也就確定了柄慰。接下來鳍悠，就讓我們來逐個分析這9種組合下的SQL加鎖策略。
注：在前面八種組合下坐搔，也就是RC藏研，RR隔離級別下，SQL1：select操作均不加鎖概行，采用的是快照讀蠢挡，因此在下面的討論中就忽略了，主要討論SQL2：delete操作的加鎖。
-
組合一：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列的索引進(jìn)行where條件的過濾，在找到id=10的記錄后叹卷，首先會將unique索引上的id=10索引記錄加上X鎖，同時坪它，會根據(jù)讀取到的name列骤竹，回主鍵索引(聚簇索引)，然后將聚簇索引上的name = ‘d’ 對應(yīng)的主鍵索引項(xiàng)加X鎖往毡。為什么聚簇索引上的記錄也要加鎖蒙揣？試想一下，如果并發(fā)的一個SQL开瞭，是通過主鍵索引來更新：update t1 set id = 100 where name = ‘d’; 此時懒震，如果delete語句沒有將主鍵索引上的記錄加鎖，那么并發(fā)的update就會感知不到delete語句的存在嗤详，違背了同一記錄上的更新/刪除需要串行執(zhí)行的約束个扰。
結(jié)論：
若id列是unique列，其上有unique索引葱色。那么SQL需要加兩個X鎖递宅，一個對應(yīng)于id unique索引上的id = 10的記錄，另一把鎖對應(yīng)于聚簇索引上的[name=’d’,id=10]的記錄。
-
組合三：id非唯一索引+RC
相對于組合一办龄、二烘绽，組合三又發(fā)生了變化，隔離級別仍舊是RC不變俐填，但是id列上的約束又降低了安接，id列不再唯一，只有一個普通的索引英融。假設(shè)delete from t1 where id = 10; 語句盏檐，仍舊選擇id列上的索引進(jìn)行過濾where條件，那么此時會持有哪些鎖矢赁？同樣見下圖：
根據(jù)此圖糯笙，可以看到，首先撩银，id列索引上给涕，滿足id = 10查詢條件的記錄，均已加鎖额获。同時够庙，這些記錄對應(yīng)的主鍵索引上的記錄也都加上了鎖。與組合二唯一的區(qū)別在于抄邀，組合二最多只有一個滿足等值查詢的記錄耘眨，而組合三會將所有滿足查詢條件的記錄都加鎖。
結(jié)論：
若id列上有非唯一索引境肾，那么對應(yīng)的所有滿足SQL查詢條件的記錄剔难，都會被加鎖。同時奥喻，這些記錄在主鍵索引上的記錄偶宫，也會被加鎖。
-
組合四：id無索引+RC
相對于前面三個組合环鲤，這是一個比較特殊的情況纯趋。id列上沒有索引，where id = 10;這個過濾條件冷离，沒法通過索引進(jìn)行過濾吵冒，那么只能走全表掃描做過濾。對應(yīng)于這個組合西剥，SQL會加什么鎖痹栖？或者是換句話說，全表掃描時蔫耽，會加什么鎖结耀？這個答案也有很多：有人說會在表上加X鎖留夜；有人說會將聚簇索引上，選擇出來的id = 10;的記錄加上X鎖图甜。那么實(shí)際情況呢碍粥？請看下圖：
由于id列上沒有索引，因此只能走聚簇索引黑毅，進(jìn)行全部掃描嚼摩。從圖中可以看到，滿足刪除條件的記錄有兩條矿瘦，但是枕面，聚簇索引上所有的記錄，都被加上了X鎖缚去。無論記錄是否滿足條件潮秘，全部被加上X鎖。既不是加表鎖易结，也不是在滿足條件的記錄上加行鎖枕荞。
有人可能會問？為什么不是只在滿足條件的記錄上加鎖呢搞动？這是由于MySQL的實(shí)現(xiàn)決定的躏精。如果一個條件無法通過索引快速過濾，那么存儲引擎層面就會將所有記錄加鎖后返回鹦肿，然后由MySQL Server層進(jìn)行過濾矗烛。因此也就把所有的記錄，都鎖上了箩溃。
注：在實(shí)際的實(shí)現(xiàn)中瞭吃，MySQL有一些改進(jìn)，在MySQL Server過濾條件涣旨，發(fā)現(xiàn)不滿足后虱而，會調(diào)用unlock_row方法，把不滿足條件的記錄放鎖 (違背了2PL的約束)开泽。這樣做，保證了最后只會持有滿足條件記錄上的鎖魁瞪，但是每條記錄的加鎖操作還是不能省略的穆律。
結(jié)論：
若id列上沒有索引，SQL會走聚簇索引的全掃描進(jìn)行過濾导俘，由于過濾是由MySQL Server層面進(jìn)行的峦耘。因此每條記錄，無論是否滿足條件旅薄，都會被加上X鎖辅髓。但是泣崩，為了效率考量，MySQL做了優(yōu)化洛口，對于不滿足條件的記錄矫付，會在判斷后放鎖，最終持有的第焰，是滿足條件的記錄上的鎖买优，但是不滿足條件的記錄上的加鎖/放鎖動作不會省略。同時挺举，優(yōu)化也違背了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唯一索引滿足條件的記錄上一個，對應(yīng)的聚簇索引上的記錄一個常挚。
-
組合七：id非唯一索引+RR
還記得前面提到的MySQL的四種隔離級別的區(qū)別嗎作谭？RC隔離級別允許幻讀，而RR隔離級別奄毡，不允許存在幻讀折欠。但是在組合五、組合六中吼过，加鎖行為又是與RC下的加鎖行為完全一致锐秦。那么RR隔離級別下，如何防止幻讀呢盗忱？問題的答案酱床，就在組合七中揭曉。
組合七趟佃，Repeatable Read隔離級別扇谣，id上有一個非唯一索引昧捷，執(zhí)行delete from t1 where id = 10; 假設(shè)選擇id列上的索引進(jìn)行條件過濾，最后的加鎖行為罐寨，是怎么樣的呢靡挥？同樣看下面這幅圖：
此圖，相對于組合三：[id列上非唯一鎖衩茸，Read Committed]看似相同芹血，其實(shí)卻有很大的區(qū)別。最大的區(qū)別在于楞慈，這幅圖中多了一個GAP鎖幔烛，而且GAP鎖看起來也不是加在記錄上的，倒像是加載兩條記錄之間的位置囊蓝，GAP鎖有何用饿悬？
其實(shí)這個多出來的GAP鎖，就是RR隔離級別聚霜，相對于RC隔離級別狡恬，不會出現(xiàn)幻讀的關(guān)鍵。確實(shí)蝎宇，GAP鎖鎖住的位置弟劲，也不是記錄本身，而是兩條記錄之間的GAP姥芥。所謂幻讀兔乞，就是同一個事務(wù)，連續(xù)做兩次當(dāng)前讀 (例如：select * from t1 where id = 10 for update;)凉唐，那么這兩次當(dāng)前讀返回的是完全相同的記錄 (記錄數(shù)量一致庸追，記錄本身也一致)，第二次的當(dāng)前讀台囱，不會比第一次返回更多的記錄 (幻象)淡溯。
如何保證兩次當(dāng)前讀返回一致的記錄，那就需要在第一次當(dāng)前讀與第二次當(dāng)前讀之間簿训，其他的事務(wù)不會插入新的滿足條件的記錄并提交咱娶。為了實(shí)現(xiàn)這個功能，GAP鎖應(yīng)運(yùn)而生强品。
如圖中所示豺总，有哪些位置可以插入新的滿足條件的項(xiàng) (id = 10)，考慮到B+樹索引的有序性择懂，滿足條件的項(xiàng)一定是連續(xù)存放的。記錄[6,c]之前另玖，不會插入id=10的記錄困曙；<a name="OLE_LINK1" style="margin: 0px; padding: 0px; color: rgb(34, 85, 136); text-decoration: none;"></a>[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不能插入記錄苇经。因此赘理，通過第一遍的當(dāng)前讀，不僅將滿足條件的記錄鎖上 (X鎖)扇单，與組合三類似商模。同時還是增加3把GAP鎖，將可能插入滿足條件記錄的3個GAP給鎖上令花，保證后續(xù)的Insert不能插入新的id=10的記錄阻桅，也就杜絕了同一事務(wù)的第二次當(dāng)前讀，出現(xiàn)幻象的情況兼都。
有心的朋友看到這兒嫂沉，可以會問：既然防止幻讀，需要靠GAP鎖的保護(hù)扮碧，為什么組合五趟章、組合六，也是RR隔離級別慎王，卻不需要加GAP鎖呢蚓土？
首先，這是一個好問題赖淤。其次蜀漆，回答這個問題，也很簡單咱旱。GAP鎖的目的确丢，是為了防止同一事務(wù)的兩次當(dāng)前讀绷耍，出現(xiàn)幻讀的情況。而組合五鲜侥，id是主鍵褂始；組合六，id是unique鍵描函，都能夠保證唯一性崎苗。一個等值查詢，最多只能返回一條記錄舀寓，而且新的相同取值的記錄胆数，一定不會在新插入進(jìn)來，因此也就避免了GAP鎖的使用基公。其實(shí)幅慌，針對此問題，還有一個更深入的問題：
如果組合五轰豆、組合六下胰伍，針對SQL：select * from t1 where id = 10 for update; 第一次查詢，沒有找到滿足查詢條件的記錄酸休，那么GAP鎖是否還能夠省略骂租？
此問題留給大家思考。
結(jié)論：
Repeatable Read隔離級別下斑司，id列上有一個非唯一索引渗饮，對應(yīng)SQL：delete from t1 where id = 10; 首先，通過id索引定位到第一條滿足查詢條件的記錄宿刮，加記錄上的X鎖互站，加GAP上的GAP鎖，然后加主鍵聚簇索引上的記錄X鎖僵缺，然后返回胡桃；然后讀取下一條，重復(fù)進(jìn)行磕潮。直至進(jìn)行到第一條不滿足條件的記錄[11,f]翠胰，此時，不需要加記錄X鎖自脯，但是仍舊需要加GAP鎖之景，最后返回結(jié)束。
-
組合八：id無索引+RR
組合八膏潮，Repeatable Read隔離級別下的最后一種情況锻狗，id列上沒有索引。此時SQL：delete from t1 where id = 10; 沒有其他的路徑可以選擇，只能進(jìn)行全表掃描轻纪。最終的加鎖情況脚囊，如下圖所示：
如圖，這是一個很恐怖的現(xiàn)象桐磁。首先，聚簇索引上的所有記錄讲岁，都被加上了X鎖我擂。其次，聚簇索引每條記錄間的間隙(GAP)缓艳，也同時被加上了GAP鎖校摩。這個示例表，只有6條記錄阶淘，一共需要6個記錄鎖衙吩，7個GAP鎖。試想溪窒，如果表上有1000萬條記錄呢坤塞？
在這種情況下，這個表上澈蚌，除了不加鎖的快照度摹芙，其他任何加鎖的并發(fā)SQL，均不能執(zhí)行宛瞄，不能更新浮禾，不能刪除，不能插入份汗，全表被鎖死盈电。
當(dāng)然，跟組合四：[id無索引, Read Committed]類似杯活，這個情況下匆帚，MySQL也做了一些優(yōu)化，就是所謂的semi-consistent read轩猩。semi-consistent read開啟的情況下卷扮，對于不滿足查詢條件的記錄，MySQL會提前放鎖均践。針對上面的這個用例晤锹，就是除了記錄[d,10]，[g,10]之外彤委，所有的記錄鎖都會被釋放鞭铆，同時不加GAP鎖。semi-consistent read如何觸發(fā)：要么是read committed隔離級別；要么是Repeatable Read隔離級別车遂，同時設(shè)置了
innodb_locks_unsafe_for_binlog
參數(shù)封断。更詳細(xì)的關(guān)于semi-consistent read的介紹，可參考我之前的一篇博客：MySQL+InnoDB semi-consitent read原理及實(shí)現(xiàn)分析
舶担。
結(jié)論：
在Repeatable Read隔離級別下坡疼，如果進(jìn)行全表掃描的當(dāng)前讀，那么會鎖上表中的所有記錄衣陶，同時會鎖上聚簇索引內(nèi)的所有GAP柄瑰，杜絕所有的并發(fā) 更新/刪除/插入 操作。當(dāng)然剪况，也可以通過觸發(fā)semi-consistent read教沾，來緩解加鎖開銷與并發(fā)影響，但是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會加讀鎖，也就是說快照讀不復(fù)存在寇荧，MVCC并發(fā)控制降級為Lock-Based CC举庶。
結(jié)論：在MySQL/InnoDB中，所謂的讀不加鎖揩抡，并不適用于所有的情況户侥，而是隔離級別相關(guān)的。Serializable隔離級別峦嗤，讀不加鎖就不再成立蕊唐，所有的讀操作，都是當(dāng)前讀烁设。
-
一條復(fù)雜的SQL
寫到這里替梨，其實(shí)MySQL的加鎖實(shí)現(xiàn)也已經(jīng)介紹的八八九九。只要將本文上面的分析思路，大部分的SQL副瀑，都能分析出其會加哪些鎖弓熏。而這里，再來看一個稍微復(fù)雜點(diǎn)的SQL糠睡，用于說明MySQL加鎖的另外一個邏輯挽鞠。SQL用例如下：
如圖中的SQL，會加什么鎖狈孔？假定在Repeatable Read隔離級別下 (Read Committed隔離級別下的加鎖情況滞谢，留給讀者分析。)除抛，同時，假設(shè)SQL走的是idx_t1_pu索引母截。
在詳細(xì)分析這條SQL的加鎖情況前到忽，還需要有一個知識儲備，那就是一個SQL中的where條件如何拆分清寇？具體的介紹喘漏，建議閱讀我之前的一篇文章：SQL中的where條件，在數(shù)據(jù)庫中提取與應(yīng)用淺析
华烟。在這里翩迈，我直接給出分析后的結(jié)果：
-
Index key：
pubtime > 1 and puptime < 20。此條件盔夜，用于確定SQL在idx_t1_pu索引上的查詢范圍负饲。
-
Index Filter：
userid = ‘hdc’ 。此條件喂链，可以在idx_t1_pu索引上進(jìn)行過濾返十，但不屬于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鎖 (圖中拾稳，用紅色箭頭標(biāo)出的X鎖吮炕，是否要加，視是否支持ICP而定)访得；而Table Filter對應(yīng)的過濾條件龙亲，則在聚簇索引中讀取后，在MySQL Server層面過濾悍抑，因此聚簇索引上也需要X鎖芍秆。最后蚂蕴，選取出了一條滿足條件的記錄[8,hdc,d,5,good]，但是加鎖的數(shù)量，要遠(yuǎn)遠(yuǎn)大于滿足條件的記錄數(shù)量诉位。
結(jié)論：
在Repeatable Read隔離級別下赎婚，針對一個復(fù)雜的SQL逊彭，首先需要提取其where條件瓦戚。Index Key確定的范圍，需要加上GAP鎖摸吠；Index Filter過濾條件榕订，視MySQL版本是否支持ICP，若支持ICP蜕便，則不滿足Index Filter的記錄劫恒，不加X鎖，否則需要X鎖轿腺；Table Filter過濾條件两嘴，無論是否滿足，都需要加X鎖族壳。
-
死鎖原理與分析
本文前面的部分憔辫，基本上已經(jīng)涵蓋了MySQL/InnoDB所有的加鎖規(guī)則。深入理解MySQL如何加鎖仿荆，有兩個比較重要的作用：
可以根據(jù)MySQL的加鎖規(guī)則贰您，寫出不會發(fā)生死鎖的SQL坏平；
可以根據(jù)MySQL的加鎖規(guī)則，定位出線上產(chǎn)生死鎖的原因锦亦；
下面舶替，來看看兩個死鎖的例子 (一個是兩個Session的兩條SQL產(chǎn)生死鎖；另一個是兩個Session的一條SQL杠园，產(chǎn)生死鎖)：
上面的兩個死鎖用例顾瞪。第一個非常好理解，也是最常見的死鎖抛蚁，每個事務(wù)執(zhí)行兩條SQL陈醒，分別持有了一把鎖，然后加另一把鎖瞧甩，產(chǎn)生死鎖钉跷。
第二個用例，雖然每個Session都只有一條語句肚逸，仍舊會產(chǎn)生死鎖尘应。要分析這個死鎖，首先必須用到本文前面提到的MySQL加鎖的規(guī)則吼虎。針對Session 1，從name索引出發(fā)苍鲜，讀到的[hdc, 1]思灰，[hdc, 6]均滿足條件，不僅會加name索引上的記錄X鎖混滔，而且會加聚簇索引上的記錄X鎖洒疚，加鎖順序?yàn)橄萚1,hdc,100]，后[6,hdc,10]坯屿。而Session 2油湖，從pubtime索引出發(fā)，[10,6],[100,1]均滿足過濾條件领跛，同樣也會加聚簇索引上的記錄X鎖乏德，加鎖順序?yàn)閇6,hdc,10]，后[1,hdc,100]吠昭。發(fā)現(xiàn)沒有喊括，跟Session 1的加鎖順序正好相反，如果兩個Session恰好都持有了第一把鎖矢棚，請求加第二把鎖郑什，死鎖就發(fā)生了。
結(jié)論：
死鎖的發(fā)生與否蒲肋，并不在于事務(wù)中有多少條SQL語句蘑拯，死鎖的關(guān)鍵在于：兩個(或以上)的Session
加鎖的順序
不一致钝满。而使用本文上面提到的，分析MySQL每條SQL語句的加鎖規(guī)則申窘，分析出每條語句的加鎖順序弯蚜，然后檢查多個并發(fā)SQL間是否存在以相反的順序加鎖的情況，就可以分析出各種潛在的死鎖情況偶洋，也可以分析出線上死鎖發(fā)生的原因熟吏。
-
總結(jié)
寫到這兒，本文也告一段落玄窝，做一個簡單的總結(jié)牵寺，要做的完全掌握MySQL/InnoDB的加鎖規(guī)則，甚至是其他任何數(shù)據(jù)庫的加鎖規(guī)則恩脂，需要具備以下的一些知識點(diǎn)：
了解數(shù)據(jù)庫的一些基本理論知識：數(shù)據(jù)的存儲格式 (堆組織表 vs 聚簇索引表)帽氓；并發(fā)控制協(xié)議 (MVCC vs Lock-Based CC)；Two-Phase Locking俩块；數(shù)據(jù)庫的隔離級別定義 (Isolation Level)黎休；
了解SQL本身的執(zhí)行計(jì)劃 (主鍵掃描 vs 唯一鍵掃描 vs 范圍掃描 vs 全表掃描)；
了解數(shù)據(jù)庫本身的一些實(shí)現(xiàn)細(xì)節(jié) (過濾條件提扔窨势腮；Index Condition Pushdown；Semi-Consistent Read)漫仆；
了解死鎖產(chǎn)生的原因及分析的方法 (加鎖順序不一致捎拯；分析每個SQL的加鎖順序)
有了這些知識點(diǎn)，再加上適當(dāng)?shù)膶?shí)戰(zhàn)經(jīng)驗(yàn)盲厌，全面掌控MySQL/InnoDB的加鎖規(guī)則署照，當(dāng)不在話下。
