1背景????1
1.1MVCC：Snapshot Read vs Current Read????2
2一條簡(jiǎn)單SQL的加鎖實(shí)現(xiàn)分析????5
背景
MySQL/InnoDB的加鎖分析幸斥，一直是一個(gè)比較困難的話題呆奕。我在工作過(guò)程中焕襟，經(jīng)常會(huì)有同事咨詢這方面的問(wèn)題第喳。同時(shí)，微博上也經(jīng)常會(huì)收到MySQL鎖相關(guān)的私信膀曾，讓我?guī)椭鉀Q一些死鎖的問(wèn)題瘫筐。本文旱眯，準(zhǔn)備就MySQL/InnoDB的加鎖問(wèn)題盟蚣，展開較為深入的分析與討論黍析，主要是介紹一種思路，運(yùn)用此思路屎开，拿到任何一條SQL語(yǔ)句，都能完整的分析出這條語(yǔ)句會(huì)加什么鎖？會(huì)有什么樣的使用風(fēng)險(xiǎn)奄抽？甚至是分析線上的一個(gè)死鎖場(chǎng)景蔼两，了解死鎖產(chǎn)生的原因。
注：MySQL是一個(gè)支持插件式存儲(chǔ)引擎的數(shù)據(jù)庫(kù)系統(tǒng)逞度。本文下面的所有介紹额划，都是基于InnoDB存儲(chǔ)引擎，其他引擎的表現(xiàn)档泽，會(huì)有較大的區(qū)別俊戳。
MVCC：Snapshot Read vs Current Read
MySQL InnoDB存儲(chǔ)引擎，實(shí)現(xiàn)的是基于多版本的并發(fā)控制協(xié)議——MVCC (Multi-Version Concurrency Control) (注：與MVCC相對(duì)的馆匿，是基于鎖的并發(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)前讀返回的記錄析显，都會(huì)加上鎖鲫咽，保證其他事務(wù)不會(huì)再并發(fā)修改這條記錄。
在一個(gè)支持MVCC并發(fā)控制的系統(tǒng)中，哪些讀操作是快照讀分尸？哪些操作又是當(dāng)前讀呢锦聊？以MySQL InnoDB為例：
快照讀：簡(jiǎn)單的select操作，屬于快照讀箩绍，不加鎖孔庭。(當(dāng)然，也有例外材蛛，下面會(huì)分析)
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 ?;
所有以上的語(yǔ)句，都屬于當(dāng)前讀陨簇，讀取記錄的最新版本。并且己单，讀取之后纹笼，還需要保證其他并發(fā)事務(wù)不能修改當(dāng)前記錄，對(duì)讀取記錄加鎖笋额。其中兄猩，除了第一條語(yǔ)句，對(duì)讀取記錄加S鎖 (共享鎖)外淹真，其他的操作核蘸，都加的是X鎖 (排它鎖)鳞贷。
為什么將 插入/更新/刪除 操作，都?xì)w為當(dāng)前讀疆偿？可以看看下面這個(gè) 更新 操作杆故，在數(shù)據(jù)庫(kù)中的執(zhí)行流程：
從圖中，可以看到拐揭，一個(gè)Update操作的具體流程家肯。當(dāng)Update SQL被發(fā)給MySQL后讨衣，MySQL Server會(huì)根據(jù)where條件反镇，讀取第一條滿足條件的記錄，然后InnoDB引擎會(huì)將第一條記錄返回辆亏，并加鎖 (current read)扮叨。待MySQL Server收到這條加鎖的記錄之后碍沐，會(huì)再發(fā)起一個(gè)Update請(qǐng)求累提，更新這條記錄。一條記錄操作完成无虚，再讀取下一條記錄友题，直至沒有滿足條件的記錄為止。因此戈抄，Update操作內(nèi)部呛凶，就包含了一個(gè)當(dāng)前讀。同理建瘫，Delete操作也一樣殷蛇。Insert操作會(huì)稍微有些不同粒梦，簡(jiǎn)單來(lái)說(shuō)匀们，就是Insert操作可能會(huì)觸發(fā)Unique Key的沖突檢查重抖，也會(huì)進(jìn)行一個(gè)當(dāng)前讀钟沛。
注：根據(jù)上圖的交互，針對(duì)一條當(dāng)前讀的SQL語(yǔ)句延欠，InnoDB與MySQL Server的交互，是一條一條進(jìn)行的，因此涧窒，加鎖也是一條一條進(jìn)行的纠吴。先對(duì)一條滿足條件的記錄加鎖，返回給MySQL Server，做一些DML操作握联；然后在讀取下一條加鎖金闽，直至讀取完畢。
Cluster Index：聚簇索引
InnoDB存儲(chǔ)引擎的數(shù)據(jù)組織方式蜒犯，是聚簇索引表：完整的記錄罚随，存儲(chǔ)在主鍵索引中遵班，通過(guò)主鍵索引，就可以獲取記錄所有的列翰萨。關(guān)于聚簇索引表的組織方式，可以參考MySQL的官方文檔：Clustered and Secondary Indexes雳锋。本文假設(shè)讀者對(duì)這個(gè)，已經(jīng)有了一定的認(rèn)識(shí)辛蚊，就不再做具體的介紹。接下來(lái)的部分飞蛹，主鍵索引/聚簇索引 兩個(gè)名稱卧檐，會(huì)有一些混用，望讀者知曉焰宣。
2PL：Two-Phase Locking
傳統(tǒng)RDBMS加鎖的一個(gè)原則霉囚，就是2PL (二階段鎖)：Two-Phase Locking。相對(duì)而言匕积，2PL比較容易理解盈罐，說(shuō)的是鎖操作分為兩個(gè)階段：加鎖階段與解鎖階段榜跌，并且保證加鎖階段與解鎖階段不相交。下面票顾，仍舊以MySQL為例影锈，來(lái)簡(jiǎn)單看看2PL在MySQL中的實(shí)現(xiàn)沃但。
從上圖可以看出陨仅，2PL就是將加鎖/解鎖分為兩個(gè)完全不相交的階段。加鎖階段：只加鎖，不放鎖惶室。解鎖階段：只放鎖，不加鎖丙者。
Isolation Level
隔離級(jí)別：Isolation Level，也是RDBMS的一個(gè)關(guān)鍵特性。相信對(duì)數(shù)據(jù)庫(kù)有所了解的朋友，對(duì)于4種隔離級(jí)別：Read Uncommited，Read Committed示损，Repeatable Read卖氨，Serializable村斟，都有了深入的認(rèn)識(shí)败匹。本文不打算討論數(shù)據(jù)庫(kù)理論中缆巧，是如何定義這4種隔離級(jí)別的含義的裂问，而是跟大家介紹一下MySQL/InnoDB是如何定義這4種隔離級(jí)別的蛾魄。
MySQL/InnoDB定義的4種隔離級(jí)別：
Read Uncommited
可以讀取未提交記錄痛侍。此隔離級(jí)別将宪，不會(huì)使用，忽略。
Read Committed (RC)
快照讀忽略床嫌，本文不考慮。
針對(duì)當(dāng)前讀胸私，RC隔離級(jí)別保證對(duì)讀取到的記錄加鎖 (記錄鎖)厌处，存在幻讀現(xiàn)象。
Repeatable Read (RR)
快照讀忽略岁疼，本文不考慮嘱蛋。
針對(duì)當(dāng)前讀，RR隔離級(jí)別保證對(duì)讀取到的記錄加鎖 (記錄鎖)五续，同時(shí)保證對(duì)讀取的范圍加鎖，新的滿足查詢條件的記錄不能夠插入 (間隙鎖)龄恋，不存在幻讀現(xiàn)象疙驾。
Serializable
從MVCC并發(fā)控制退化為基于鎖的并發(fā)控制。不區(qū)別快照讀與當(dāng)前讀郭毕，所有的讀操作均為當(dāng)前讀它碎，讀加讀鎖 (S鎖)，寫加寫鎖 (X鎖)。
Serializable隔離級(jí)別下扳肛，讀寫沖突傻挂，因此并發(fā)度急劇下降，在MySQL/InnoDB下不建議使用挖息。
一條簡(jiǎn)單SQL的加鎖實(shí)現(xiàn)分析
在介紹完一些背景知識(shí)之后金拒，本文接下來(lái)將選擇幾個(gè)有代表性的例子，來(lái)詳細(xì)分析MySQL的加鎖處理套腹。當(dāng)然绪抛，還是從最簡(jiǎn)單的例子說(shuō)起。經(jīng)常有朋友發(fā)給我一個(gè)SQL电禀，然后問(wèn)我幢码，這個(gè)SQL加什么鎖？就如同下面兩條簡(jiǎn)單的SQL尖飞，他們加什么鎖症副？
SQL1：select * from t1 where id = 10;
SQL2：delete from t1 where id = 10;
針對(duì)這個(gè)問(wèn)題，該怎么回答政基？我能想象到的一個(gè)答案是：
SQL1：不加鎖贞铣。因?yàn)镸ySQL是使用多版本并發(fā)控制的，讀不加鎖腋么。
SQL2：對(duì)id = 10的記錄加寫鎖 (走主鍵索引)咕娄。
這個(gè)答案對(duì)嗎？說(shuō)不上來(lái)珊擂。即可能是正確的圣勒，也有可能是錯(cuò)誤的，已知條件不足摧扇，這個(gè)問(wèn)題沒有答案圣贸。如果讓我來(lái)回答這個(gè)問(wèn)題，我必須還要知道以下的一些前提扛稽，前提不同吁峻，我能給出的答案也就不同。要回答這個(gè)問(wèn)題在张，還缺少哪些前提條件用含？
前提一：id列是不是主鍵？
前提二：當(dāng)前系統(tǒng)的隔離級(jí)別是什么帮匾？
前提三：id列如果不是主鍵啄骇，那么id列上有索引嗎？
前提四：id列上如果有二級(jí)索引瘟斜，那么這個(gè)索引是唯一索引嗎缸夹？
前提五：兩個(gè)SQL的執(zhí)行計(jì)劃是什么痪寻？索引掃描？全表掃描虽惭？
沒有這些前提橡类，直接就給定一條SQL，然后問(wèn)這個(gè)SQL會(huì)加什么鎖芽唇，都是很業(yè)余的表現(xiàn)顾画。而當(dāng)這些問(wèn)題有了明確的答案之后，給定的SQL會(huì)加什么鎖披摄，也就一目了然亲雪。下面，我將這些問(wèn)題的答案進(jìn)行組合疚膊，然后按照從易到難的順序义辕，逐個(gè)分析每種組合下，對(duì)應(yīng)的SQL會(huì)加哪些鎖寓盗？
注：下面的這些組合灌砖，我做了一個(gè)前提假設(shè)，也就是有索引時(shí)傀蚌，執(zhí)行計(jì)劃一定會(huì)選擇使用索引進(jìn)行過(guò)濾 (索引掃描)基显。但實(shí)際情況會(huì)復(fù)雜很多，真正的執(zhí)行計(jì)劃善炫，還是需要根據(jù)MySQL輸出的為準(zhǔn)撩幽。
組合一：id列是主鍵，RC隔離級(jí)別
組合二：id列是二級(jí)唯一索引箩艺，RC隔離級(jí)別
組合三：id列是二級(jí)非唯一索引窜醉，RC隔離級(jí)別
組合四：id列上沒有索引，RC隔離級(jí)別
組合五：id列是主鍵艺谆，RR隔離級(jí)別
組合六：id列是二級(jí)唯一索引榨惰，RR隔離級(jí)別
組合七：id列是二級(jí)非唯一索引，RR隔離級(jí)別
組合八：id列上沒有索引静汤，RR隔離級(jí)別
組合九：Serializable隔離級(jí)別
排列組合還沒有列舉完全琅催，但是看起來(lái)，已經(jīng)很多了虫给。真的有必要這么復(fù)雜嗎藤抡？事實(shí)上，要分析加鎖抹估，就是需要這么復(fù)雜杰捂。但是從另一個(gè)角度來(lái)說(shuō)，只要你選定了一種組合棋蚌，SQL需要加哪些鎖嫁佳，其實(shí)也就確定了。接下來(lái)谷暮，就讓我們來(lái)逐個(gè)分析這9種組合下的SQL加鎖策略蒿往。
注：在前面八種組合下，也就是RC湿弦，RR隔離級(jí)別下瓤漏，SQL1：select操作均不加鎖，采用的是快照讀颊埃，因此在下面的討論中就忽略了蔬充，主要討論SQL2：delete操作的加鎖。
組合一：id主鍵+RC
這個(gè)組合班利，是最簡(jiǎn)單饥漫，最容易分析的組合。id是主鍵罗标，Read Committed隔離級(jí)別庸队，給定SQL：delete from t1 where id = 10; 只需要將主鍵上，id = 10的記錄加上X鎖即可闯割。如下圖所示：
結(jié)論：id是主鍵時(shí)彻消，此SQL只需要在id=10這條記錄上加X鎖即可。
組合二：id唯一索引+RC
這個(gè)組合宙拉，id不是主鍵宾尚，而是一個(gè)Unique的二級(jí)索引鍵值。那么在RC隔離級(jí)別下谢澈，delete from t1 where id = 10; 需要加什么鎖呢煌贴？見下圖：
此組合中，id是unique索引澳化，而主鍵是name列崔步。此時(shí)，加鎖的情況由于組合一有所不同缎谷。由于id是unique索引井濒，因此delete語(yǔ)句會(huì)選擇走id列的索引進(jìn)行where條件的過(guò)濾，在找到id=10的記錄后列林，首先會(huì)將unique索引上的id=10索引記錄加上X鎖瑞你，同時(shí)，會(huì)根據(jù)讀取到的name列希痴，回主鍵索引(聚簇索引)者甲，然后將聚簇索引上的name = ‘d’ 對(duì)應(yīng)的主鍵索引項(xiàng)加X鎖。為什么聚簇索引上的記錄也要加鎖砌创？試想一下虏缸，如果并發(fā)的一個(gè)SQL鲫懒，是通過(guò)主鍵索引來(lái)更新：update t1 set id = 100 where name = ‘d’; 此時(shí)，如果delete語(yǔ)句沒有將主鍵索引上的記錄加鎖刽辙，那么并發(fā)的update就會(huì)感知不到delete語(yǔ)句的存在窥岩，違背了同一記錄上的更新/刪除需要串行執(zhí)行的約束。
結(jié)論：若id列是unique列宰缤，其上有unique索引颂翼。那么SQL需要加兩個(gè)X鎖，一個(gè)對(duì)應(yīng)于id unique索引上的id = 10的記錄慨灭，另一把鎖對(duì)應(yīng)于聚簇索引上的[name=’d’,id=10]的記錄朦乏。
組合三：id非唯一索引+RC
相對(duì)于組合一、二氧骤，組合三又發(fā)生了變化呻疹，隔離級(jí)別仍舊是RC不變，但是id列上的約束又降低了语淘，id列不再唯一诲宇，只有一個(gè)普通的索引。假設(shè)delete from t1 where id = 10; 語(yǔ)句惶翻，仍舊選擇id列上的索引進(jìn)行過(guò)濾where條件姑蓝，那么此時(shí)會(huì)持有哪些鎖？同樣見下圖：
根據(jù)此圖吕粗，可以看到纺荧，首先，id列索引上颅筋，滿足id = 10查詢條件的記錄宙暇，均已加鎖。同時(shí)议泵，這些記錄對(duì)應(yīng)的主鍵索引上的記錄也都加上了鎖占贫。與組合二唯一的區(qū)別在于，組合二最多只有一個(gè)滿足等值查詢的記錄先口，而組合三會(huì)將所有滿足查詢條件的記錄都加鎖型奥。
結(jié)論：若id列上有非唯一索引，那么對(duì)應(yīng)的所有滿足SQL查詢條件的記錄碉京，都會(huì)被加鎖厢汹。同時(shí)，這些記錄在主鍵索引上的記錄谐宙，也會(huì)被加鎖烫葬。
組合四：id無(wú)索引+RC
相對(duì)于前面三個(gè)組合，這是一個(gè)比較特殊的情況。id列上沒有索引搭综，where id = 10;這個(gè)過(guò)濾條件垢箕，沒法通過(guò)索引進(jìn)行過(guò)濾，那么只能走全表掃描做過(guò)濾兑巾。對(duì)應(yīng)于這個(gè)組合舰讹，SQL會(huì)加什么鎖？或者是換句話說(shuō)闪朱，全表掃描時(shí)，會(huì)加什么鎖钻洒？這個(gè)答案也有很多：有人說(shuō)會(huì)在表上加X鎖奋姿；有人說(shuō)會(huì)將聚簇索引上，選擇出來(lái)的id = 10;的記錄加上X鎖素标。那么實(shí)際情況呢称诗？請(qǐng)看下圖：
由于id列上沒有索引，因此只能走聚簇索引头遭，進(jìn)行全部掃描寓免。從圖中可以看到，滿足刪除條件的記錄有兩條计维，但是袜香，聚簇索引上所有的記錄，都被加上了X鎖鲫惶。無(wú)論記錄是否滿足條件蜈首，全部被加上X鎖。既不是加表鎖欠母，也不是在滿足條件的記錄上加行鎖欢策。
有人可能會(huì)問(wèn)？為什么不是只在滿足條件的記錄上加鎖呢赏淌？這是由于MySQL的實(shí)現(xiàn)決定的踩寇。如果一個(gè)條件無(wú)法通過(guò)索引快速過(guò)濾，那么存儲(chǔ)引擎層面就會(huì)將所有記錄加鎖后返回六水，然后由MySQL Server層進(jìn)行過(guò)濾俺孙。因此也就把所有的記錄，都鎖上了缩擂。
注：在實(shí)際的實(shí)現(xiàn)中鼠冕，MySQL有一些改進(jìn)，在MySQL Server過(guò)濾條件胯盯，發(fā)現(xiàn)不滿足后懈费，會(huì)調(diào)用unlock_row方法，把不滿足條件的記錄放鎖 (違背了2PL的約束)博脑。這樣做憎乙，保證了最后只會(huì)持有滿足條件記錄上的鎖票罐，但是每條記錄的加鎖操作還是不能省略的。
結(jié)論：若id列上沒有索引泞边，SQL會(huì)走聚簇索引的全掃描進(jìn)行過(guò)濾该押，由于過(guò)濾是由MySQL Server層面進(jìn)行的。因此每條記錄阵谚，無(wú)論是否滿足條件蚕礼，都會(huì)被加上X鎖。但是梢什，為了效率考量奠蹬，MySQL做了優(yōu)化，對(duì)于不滿足條件的記錄嗡午，會(huì)在判斷后放鎖囤躁，最終持有的，是滿足條件的記錄上的鎖荔睹，但是不滿足條件的記錄上的加鎖/放鎖動(dòng)作不會(huì)省略狸演。同時(shí)，優(yōu)化也違背了2PL的約束僻他。
組合五：id主鍵+RR
上面的四個(gè)組合宵距，都是在Read Committed隔離級(jí)別下的加鎖行為，接下來(lái)的四個(gè)組合中姜，是在Repeatable Read隔離級(jí)別下的加鎖行為消玄。
組合五，id列是主鍵列丢胚，Repeatable Read隔離級(jí)別翩瓜，針對(duì)delete from t1 where id = 10; 這條SQL，加鎖與組合一：[id主鍵携龟，Read Committed]一致兔跌。
組合六：id唯一索引+RR
與組合五類似，組合六的加鎖峡蟋，與組合二：[id唯一索引坟桅，Read Committed]一致。兩個(gè)X鎖蕊蝗，id唯一索引滿足條件的記錄上一個(gè)仅乓，對(duì)應(yīng)的聚簇索引上的記錄一個(gè)。
組合七：id非唯一索引+RR
還記得前面提到的MySQL的四種隔離級(jí)別的區(qū)別嗎蓬戚？RC隔離級(jí)別允許幻讀夸楣，而RR隔離級(jí)別，不允許存在幻讀摹恨。但是在組合五土辩、組合六中，加鎖行為又是與RC下的加鎖行為完全一致题诵。那么RR隔離級(jí)別下紧显，如何防止幻讀呢讲衫？問(wèn)題的答案，就在組合七中揭曉孵班。
組合七涉兽，Repeatable Read隔離級(jí)別，id上有一個(gè)非唯一索引篙程，執(zhí)行delete from t1 where id = 10; 假設(shè)選擇id列上的索引進(jìn)行條件過(guò)濾花椭，最后的加鎖行為，是怎么樣的呢房午？同樣看下面這幅圖：
此圖，相對(duì)于組合三：[id列上非唯一鎖丹允，Read Committed]看似相同郭厌，其實(shí)卻有很大的區(qū)別。最大的區(qū)別在于雕蔽，這幅圖中多了一個(gè)GAP鎖折柠，而且GAP鎖看起來(lái)也不是加在記錄上的，倒像是加載兩條記錄之間的位置批狐，GAP鎖有何用扇售？
其實(shí)這個(gè)多出來(lái)的GAP鎖，就是RR隔離級(jí)別嚣艇，相對(duì)于RC隔離級(jí)別承冰，不會(huì)出現(xiàn)幻讀的關(guān)鍵。確實(shí)食零，GAP鎖鎖住的位置困乒，也不是記錄本身，而是兩條記錄之間的GAP贰谣。所謂幻讀娜搂，就是同一個(gè)事務(wù)，連續(xù)做兩次當(dāng)前讀 (例如：select * from t1 where id = 10 for update;)吱抚，那么這兩次當(dāng)前讀返回的是完全相同的記錄 (記錄數(shù)量一致百宇，記錄本身也一致)，第二次的當(dāng)前讀秘豹，不會(huì)比第一次返回更多的記錄 (幻象)携御。
如何保證兩次當(dāng)前讀返回一致的記錄，那就需要在第一次當(dāng)前讀與第二次當(dāng)前讀之間，其他的事務(wù)不會(huì)插入新的滿足條件的記錄并提交因痛。為了實(shí)現(xiàn)這個(gè)功能婚苹，GAP鎖應(yīng)運(yùn)而生。
如圖中所示鸵膏，有哪些位置可以插入新的滿足條件的項(xiàng) (id = 10)膊升，考慮到B+樹索引的有序性，滿足條件的項(xiàng)一定是連續(xù)存放的谭企。記錄[6,c]之前廓译，不會(huì)插入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]之后也不會(huì)插入滿足條件的記錄征绸。因此，為了保證[6,c]與[10,b]間俄占，[10,b]與[10,d]間管怠，[10,d]與[11,f]不會(huì)插入新的滿足條件的記錄，MySQL選擇了用GAP鎖缸榄，將這三個(gè)GAP給鎖起來(lái)渤弛。
Insert操作，如insert [10,aa]甚带，首先會(huì)定位到[6,c]與[10,b]間她肯，然后在插入前，會(huì)檢查這個(gè)GAP是否已經(jīng)被鎖上鹰贵，如果被鎖上晴氨，則Insert不能插入記錄。因此碉输，通過(guò)第一遍的當(dāng)前讀瑞筐，不僅將滿足條件的記錄鎖上 (X鎖)，與組合三類似腊瑟。同時(shí)還是增加3把GAP鎖聚假，將可能插入滿足條件記錄的3個(gè)GAP給鎖上，保證后續(xù)的Insert不能插入新的id=10的記錄闰非，也就杜絕了同一事務(wù)的第二次當(dāng)前讀膘格，出現(xiàn)幻象的情況。
有心的朋友看到這兒财松，可以會(huì)問(wèn)：既然防止幻讀瘪贱，需要靠GAP鎖的保護(hù)纱控，為什么組合五、組合六菜秦，也是RR隔離級(jí)別甜害，卻不需要加GAP鎖呢？
首先球昨，這是一個(gè)好問(wèn)題尔店。其次，回答這個(gè)問(wèn)題主慰，也很簡(jiǎn)單嚣州。GAP鎖的目的，是為了防止同一事務(wù)的兩次當(dāng)前讀共螺，出現(xiàn)幻讀的情況该肴。而組合五，id是主鍵藐不；組合六匀哄，id是unique鍵，都能夠保證唯一性雏蛮。一個(gè)等值查詢拱雏，最多只能返回一條記錄，而且新的相同取值的記錄底扳，一定不會(huì)在新插入進(jìn)來(lái)，因此也就避免了GAP鎖的使用贡耽。其實(shí)衷模，針對(duì)此問(wèn)題，還有一個(gè)更深入的問(wèn)題：如果組合五蒲赂、組合六下阱冶，針對(duì)SQL：select * from t1 where id = 10 for update; 第一次查詢，沒有找到滿足查詢條件的記錄滥嘴，那么GAP鎖是否還能夠省略木蹬？此問(wèn)題留給大家思考。
結(jié)論：Repeatable Read隔離級(jí)別下若皱，id列上有一個(gè)非唯一索引镊叁，對(duì)應(yīng)SQL：delete from t1 where id = 10; 首先，通過(guò)id索引定位到第一條滿足查詢條件的記錄走触，加記錄上的X鎖晦譬，加GAP上的GAP鎖，然后加主鍵聚簇索引上的記錄X鎖互广，然后返回敛腌；然后讀取下一條卧土，重復(fù)進(jìn)行。直至進(jìn)行到第一條不滿足條件的記錄[11,f]像樊，此時(shí)尤莺，不需要加記錄X鎖，但是仍舊需要加GAP鎖生棍，最后返回結(jié)束颤霎。
組合八：id無(wú)索引+RR
組合八，Repeatable Read隔離級(jí)別下的最后一種情況足绅，id列上沒有索引捷绑。此時(shí)SQL：delete from t1 where id = 10; 沒有其他的路徑可以選擇，只能進(jìn)行全表掃描氢妈。最終的加鎖情況粹污，如下圖所示：
如圖，這是一個(gè)很恐怖的現(xiàn)象首量。首先壮吩，聚簇索引上的所有記錄，都被加上了X鎖加缘。其次鸭叙，聚簇索引每條記錄間的間隙(GAP)，也同時(shí)被加上了GAP鎖拣宏。這個(gè)示例表沈贝，只有6條記錄，一共需要6個(gè)記錄鎖勋乾，7個(gè)GAP鎖宋下。試想，如果表上有1000萬(wàn)條記錄呢辑莫？
在這種情況下学歧，這個(gè)表上，除了不加鎖的快照度各吨，其他任何加鎖的并發(fā)SQL枝笨，均不能執(zhí)行，不能更新揭蜒，不能刪除横浑，不能插入，全表被鎖死屉更。
當(dāng)然伪嫁，跟組合四：[id無(wú)索引, Read Committed]類似，這個(gè)情況下偶垮，MySQL也做了一些優(yōu)化张咳，就是所謂的semi-consistent read帝洪。semi-consistent read開啟的情況下，對(duì)于不滿足查詢條件的記錄脚猾，MySQL會(huì)提前放鎖葱峡。針對(duì)上面的這個(gè)用例，就是除了記錄[d,10]龙助，[g,10]之外砰奕，所有的記錄鎖都會(huì)被釋放，同時(shí)不加GAP鎖提鸟。semi-consistent read如何觸發(fā)：要么是read committed隔離級(jí)別军援；要么是Repeatable Read隔離級(jí)別，同時(shí)設(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í)別下赡鲜，如果進(jìn)行全表掃描的當(dāng)前讀空厌，那么會(huì)鎖上表中的所有記錄，同時(shí)會(huì)鎖上聚簇索引內(nèi)的所有GAP银酬，杜絕所有的并發(fā) 更新/刪除/插入 操作嘲更。當(dāng)然，也可以通過(guò)觸發(fā)semi-consistent read揩瞪，來(lái)緩解加鎖開銷與并發(fā)影響赋朦，但是semi-consistent read本身也會(huì)帶來(lái)其他問(wèn)題，不建議使用李破。
組合九：Serializable
針對(duì)前面提到的簡(jiǎn)單的SQL宠哄，最后一個(gè)情況：Serializable隔離級(jí)別。對(duì)于SQL2：delete from t1 where id = 10; 來(lái)說(shuō)喷屋，Serializable隔離級(jí)別與Repeatable Read隔離級(jí)別完全一致，因此不做介紹瞭恰。
Serializable隔離級(jí)別屯曹，影響的是SQL1：select * from t1 where id = 10; 這條SQL，在RC惊畏，RR隔離級(jí)別下恶耽，都是快照讀，不加鎖颜启。但是在Serializable隔離級(jí)別偷俭，SQL1會(huì)加讀鎖，也就是說(shuō)快照讀不復(fù)存在缰盏，MVCC并發(fā)控制降級(jí)為L(zhǎng)ock-Based CC涌萤。
結(jié)論：在MySQL/InnoDB中淹遵，所謂的讀不加鎖，并不適用于所有的情況负溪，而是隔離級(jí)別相關(guān)的透揣。Serializable隔離級(jí)別，讀不加鎖就不再成立川抡，所有的讀操作辐真，都是當(dāng)前讀。
一條復(fù)雜的SQL
寫到這里崖堤，其實(shí)MySQL的加鎖實(shí)現(xiàn)也已經(jīng)介紹的八八九九侍咱。只要將本文上面的分析思路，大部分的SQL密幔，都能分析出其會(huì)加哪些鎖楔脯。而這里，再來(lái)看一個(gè)稍微復(fù)雜點(diǎn)的SQL老玛，用于說(shuō)明MySQL加鎖的另外一個(gè)邏輯淤年。SQL用例如下：
如圖中的SQL，會(huì)加什么鎖蜡豹？假定在Repeatable Read隔離級(jí)別下 (Read Committed隔離級(jí)別下的加鎖情況麸粮，留給讀者分析。)镜廉，同時(shí)弄诲，假設(shè)SQL走的是idx_t1_pu索引。
在詳細(xì)分析這條SQL的加鎖情況前娇唯，還需要有一個(gè)知識(shí)儲(chǔ)備齐遵，那就是一個(gè)SQL中的where條件如何拆分？具體的介紹塔插，建議閱讀我之前的一篇文章：SQL中的where條件梗摇，在數(shù)據(jù)庫(kù)中提取與應(yīng)用淺析。在這里想许，我直接給出分析后的結(jié)果：
Index key：pubtime > 1 and puptime < 20伶授。此條件，用于確定SQL在idx_t1_pu索引上的查詢范圍流纹。
Index Filter：userid = ‘hdc’ 糜烹。此條件，可以在idx_t1_pu索引上進(jìn)行過(guò)濾漱凝，但不屬于Index Key疮蹦。
Table Filter：comment is not NULL。此條件茸炒，在idx_t1_pu索引上無(wú)法過(guò)濾愕乎，只能在聚簇索引上過(guò)濾阵苇。
在分析出SQL where條件的構(gòu)成之后，再來(lái)看看這條SQL的加鎖情況 (RR隔離級(jí)別)妆毕，如下圖所示：
從圖中可以看出慎玖，在Repeatable Read隔離級(jí)別下，由Index Key所確定的范圍笛粘，被加上了GAP鎖趁怔；Index Filter鎖給定的條件 (userid = ‘hdc’)何時(shí)過(guò)濾，視MySQL的版本而定薪前，在MySQL 5.6版本之前润努，不支持Index Condition Pushdown(ICP)，因此Index Filter在MySQL Server層過(guò)濾示括，在5.6后支持了Index Condition Pushdown铺浇，則在index上過(guò)濾。若不支持ICP垛膝，不滿足Index Filter的記錄鳍侣，也需要加上記錄X鎖，若支持ICP吼拥，則不滿足Index Filter的記錄倚聚，無(wú)需加記錄X鎖 (圖中，用紅色箭頭標(biāo)出的X鎖凿可，是否要加惑折，視是否支持ICP而定)；而Table Filter對(duì)應(yīng)的過(guò)濾條件枯跑，則在聚簇索引中讀取后惨驶，在MySQL Server層面過(guò)濾，因此聚簇索引上也需要X鎖敛助。最后粗卜，選取出了一條滿足條件的記錄[8,hdc,d,5,good]，但是加鎖的數(shù)量纳击，要遠(yuǎn)遠(yuǎn)大于滿足條件的記錄數(shù)量续扔。
結(jié)論：在Repeatable Read隔離級(jí)別下，針對(duì)一個(gè)復(fù)雜的SQL评疗，首先需要提取其where條件测砂。Index Key確定的范圍茵烈，需要加上GAP鎖百匆；Index Filter過(guò)濾條件，視MySQL版本是否支持ICP呜投，若支持ICP加匈，則不滿足Index Filter的記錄存璃，不加X鎖，否則需要X鎖雕拼；Table Filter過(guò)濾條件纵东，無(wú)論是否滿足，都需要加X鎖啥寇。
死鎖原理與分析
本文前面的部分偎球，基本上已經(jīng)涵蓋了MySQL/InnoDB所有的加鎖規(guī)則。深入理解MySQL如何加鎖辑甜，有兩個(gè)比較重要的作用：
可以根據(jù)MySQL的加鎖規(guī)則衰絮，寫出不會(huì)發(fā)生死鎖的SQL；
可以根據(jù)MySQL的加鎖規(guī)則磷醋，定位出線上產(chǎn)生死鎖的原因猫牡；
下面，來(lái)看看兩個(gè)死鎖的例子 (一個(gè)是兩個(gè)Session的兩條SQL產(chǎn)生死鎖邓线；另一個(gè)是兩個(gè)Session的一條SQL淌友，產(chǎn)生死鎖)：
上面的兩個(gè)死鎖用例。第一個(gè)非常好理解骇陈，也是最常見的死鎖震庭，每個(gè)事務(wù)執(zhí)行兩條SQL，分別持有了一把鎖缩歪，然后加另一把鎖归薛，產(chǎn)生死鎖。
第二個(gè)用例匪蝙，雖然每個(gè)Session都只有一條語(yǔ)句主籍，仍舊會(huì)產(chǎn)生死鎖。要分析這個(gè)死鎖逛球，首先必須用到本文前面提到的MySQL加鎖的規(guī)則千元。針對(duì)Session 1，從name索引出發(fā)颤绕，讀到的[hdc, 1]幸海，[hdc, 6]均滿足條件，不僅會(huì)加name索引上的記錄X鎖奥务，而且會(huì)加聚簇索引上的記錄X鎖物独，加鎖順序?yàn)橄萚1,hdc,100]，后[6,hdc,10]氯葬。而Session 2挡篓，從pubtime索引出發(fā)，[10,6],[100,1]均滿足過(guò)濾條件，同樣也會(huì)加聚簇索引上的記錄X鎖官研，加鎖順序?yàn)閇6,hdc,10]秽澳，后[1,hdc,100]。發(fā)現(xiàn)沒有戏羽，跟Session 1的加鎖順序正好相反担神，如果兩個(gè)Session恰好都持有了第一把鎖，請(qǐng)求加第二把鎖始花，死鎖就發(fā)生了妄讯。
結(jié)論：死鎖的發(fā)生與否，并不在于事務(wù)中有多少條SQL語(yǔ)句酷宵，死鎖的關(guān)鍵在于：兩個(gè)(或以上)的Session加鎖的順序不一致捞挥。而使用本文上面提到的，分析MySQL每條SQL語(yǔ)句的加鎖規(guī)則忧吟，分析出每條語(yǔ)句的加鎖順序砌函，然后檢查多個(gè)并發(fā)SQL間是否存在以相反的順序加鎖的情況，就可以分析出各種潛在的死鎖情況溜族，也可以分析出線上死鎖發(fā)生的原因讹俊。
總結(jié)
寫到這兒，本文也告一段落煌抒，做一個(gè)簡(jiǎn)單的總結(jié)仍劈，要做的完全掌握MySQL/InnoDB的加鎖規(guī)則，甚至是其他任何數(shù)據(jù)庫(kù)的加鎖規(guī)則寡壮，需要具備以下的一些知識(shí)點(diǎn)：
了解數(shù)據(jù)庫(kù)的一些基本理論知識(shí)：數(shù)據(jù)的存儲(chǔ)格式 (堆組織表 vs 聚簇索引表)贩疙；并發(fā)控制協(xié)議 (MVCC vs Lock-Based CC)；Two-Phase Locking况既；數(shù)據(jù)庫(kù)的隔離級(jí)別定義 (Isolation Level)这溅；
了解SQL本身的執(zhí)行計(jì)劃 (主鍵掃描 vs 唯一鍵掃描 vs 范圍掃描 vs 全表掃描)；
了解數(shù)據(jù)庫(kù)本身的一些實(shí)現(xiàn)細(xì)節(jié) (過(guò)濾條件提劝羧浴悲靴；Index Condition Pushdown；Semi-Consistent Read)莫其；
了解死鎖產(chǎn)生的原因及分析的方法 (加鎖順序不一致癞尚；分析每個(gè)SQL的加鎖順序)
有了這些知識(shí)點(diǎn)，再加上適當(dāng)?shù)膶?shí)戰(zhàn)經(jīng)驗(yàn)乱陡，全面掌控MySQL/InnoDB的加鎖規(guī)則浇揩，當(dāng)不在話下。
