MySQL 加鎖處理分析
轉(zhuǎn)載2013年12月13日 16:43:55
7598
原文地址：http://hedengcheng.com/?p=771
1.1MVCC：Snapshot Read vs Current Read????2
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存儲引擎冤留，實現(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操作缴啡；然后在讀取下一條加鎖，直至讀取完畢瓷们。
InnoDB存儲引擎的數(shù)據(jù)組織方式业栅，是聚簇索引表：完整的記錄，存儲在主鍵索引中谬晕，通過主鍵索引碘裕，就可以獲取記錄所有的列。關(guān)于聚簇索引表的組織方式攒钳，可以參考MySQL的官方文檔：Clustered and Secondary Indexes帮孔。本文假設(shè)讀者對這個，已經(jīng)有了一定的認(rèn)識，就不再做具體的介紹文兢。接下來的部分晤斩，主鍵索引/聚簇索引 兩個名稱，會有一些混用姆坚，望讀者知曉澳泵。
傳統(tǒng)RDBMS加鎖的一個原則，就是2PL (二階段鎖)：Two-Phase Locking兼呵。相對而言兔辅，2PL比較容易理解，說的是鎖操作分為兩個階段：加鎖階段與解鎖階段萍程，并且保證加鎖階段與解鎖階段不相交幢妄。下面，仍舊以MySQL為例茫负，來簡單看看2PL在MySQL中的實現(xiàn)蕉鸳。
從上圖可以看出，2PL就是將加鎖/解鎖分為兩個完全不相交的階段忍法。加鎖階段：只加鎖潮尝，不放鎖。解鎖階段：只放鎖饿序，不加鎖勉失。
隔離級別：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ā)控制。部分快照讀與當(dāng)前讀蔑担，所有的讀操作均為當(dāng)前讀牌废，讀加讀鎖 (S鎖)，寫加寫鎖 (X鎖)啤握。
Serializable隔離級別下鸟缕，讀寫沖突，因此并發(fā)度急劇下降排抬，在MySQL/InnoDB下不建議使用懂从。
在介紹完一些背景知識之后，本文接下來將選擇幾個有代表性的例子蹲蒲，來詳細(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：不加鎖。因為MySQL是使用多版本并發(fā)控制的浩嫌，讀不加鎖檐迟。
SQL2：對id = 10的記錄加寫鎖 (走主鍵索引)。
這個答案對嗎码耐？說不上來追迟。即可能是正確的，也有可能是錯誤的骚腥，已知條件不足敦间，這個問題沒有答案。如果讓我來回答這個問題，我必須還要知道以下的一些前提廓块，前提不同厢绝，我能給出的答案也就不同。要回答這個問題带猴，還缺少哪些前提條件昔汉？
前提一：id列是不是主鍵？
前提二：當(dāng)前系統(tǒng)的隔離級別是什么拴清？
前提三：id列如果不是主鍵靶病，那么id列上有索引嗎？
前提四：id列上如果有二級索引口予，那么這個索引是唯一索引嗎娄周？
前提五：兩個SQL的執(zhí)行計劃是什么？索引掃描沪停？全表掃描煤辨？
沒有這些前提，直接就給定一條SQL牙甫，然后問這個SQL會加什么鎖掷酗，都是很業(yè)余的表現(xiàn)。而當(dāng)這些問題有了明確的答案之后窟哺，給定的SQL會加什么鎖泻轰，也就一目了然。下面且轨，我將這些問題的答案進(jìn)行組合浮声，然后按照從易到難的順序，逐個分析每種組合下旋奢，對應(yīng)的SQL會加哪些鎖泳挥？
注：下面的這些組合，我做了一個前提假設(shè)至朗，也就是有索引時屉符，執(zhí)行計劃一定會選擇使用索引進(jìn)行過濾 (索引掃描)。但實際情況會復(fù)雜很多锹引，真正的執(zhí)行計劃矗钟，還是需要根據(jù)MySQL輸出的為準(zhǔn)。
組合一：id列是主鍵嫌变，RC隔離級別
組合二：id列是二級唯一索引吨艇，RC隔離級別
組合三：id列是二級非唯一索引，RC隔離級別
組合四：id列上沒有索引腾啥，RC隔離級別
組合五：id列是主鍵东涡，RR隔離級別
組合六：id列是二級唯一索引冯吓，RR隔離級別
組合七：id列是二級非唯一索引，RR隔離級別
組合八：id列上沒有索引疮跑，RR隔離級別
組合九：Serializable隔離級別
排列組合還沒有列舉完全组贺，但是看起來，已經(jīng)很多了祖娘。真的有必要這么復(fù)雜嗎锣披？事實上，要分析加鎖贿条，就是需要這么復(fù)雜。但是從另一個角度來說增热，只要你選定了一種組合整以，SQL需要加哪些鎖，其實也就確定了峻仇。接下來公黑，就讓我們來逐個分析這9種組合下的SQL加鎖策略。
注：在前面八種組合下摄咆，也就是RC凡蚜，RR隔離級別下，SQL1：select操作均不加鎖吭从，采用的是快照讀朝蜘，因此在下面的討論中就忽略了，主要討論SQL2：delete操作的加鎖涩金。
這個組合谱醇，是最簡單，最容易分析的組合步做。id是主鍵副渴，Read Committed隔離級別，給定SQL：delete from t1 where id = 10; 只需要將主鍵上全度，id = 10的記錄加上X鎖即可煮剧。如下圖所示：
結(jié)論：id是主鍵時，此SQL只需要在id=10這條記錄上加X鎖即可将鸵。
這個組合勉盅，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)的主鍵索引項加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]的記錄。
相對于組合一搔涝、二丝里，組合三又發(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列上沒有索引庆揪，where id = 10;這個過濾條件，沒法通過索引進(jìn)行過濾妨托，那么只能走全表掃描做過濾。對應(yīng)于這個組合吝羞，SQL會加什么鎖兰伤？或者是換句話說，全表掃描時钧排，會加什么鎖敦腔？這個答案也有很多：有人說會在表上加X鎖；有人說會將聚簇索引上恨溜，選擇出來的id = 10;的記錄加上X鎖符衔。那么實際情況呢？請看下圖：
由于id列上沒有索引糟袁，因此只能走聚簇索引判族，進(jìn)行全部掃描。從圖中可以看到头岔，滿足刪除條件的記錄有兩條故爵，但是牙勘，聚簇索引上所有的記錄，都被加上了X鎖辩撑。無論記錄是否滿足條件，全部被加上X鎖仿耽。既不是加表鎖合冀，也不是在滿足條件的記錄上加行鎖。
有人可能會問项贺？為什么不是只在滿足條件的記錄上加鎖呢君躺？這是由于MySQL的實現(xiàn)決定的峭判。如果一個條件無法通過索引快速過濾，那么存儲引擎層面就會將所有記錄加鎖后返回晰洒，然后由MySQL Server層進(jìn)行過濾朝抖。因此也就把所有的記錄，都鎖上了谍珊。
注：在實際的實現(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的約束止剖。
上面的四個組合，都是在Read Committed隔離級別下的加鎖行為落君，接下來的四個組合穿香，是在Repeatable Read隔離級別下的加鎖行為。
組合五绎速，id列是主鍵列皮获，Repeatable Read隔離級別，針對delete from t1 where id = 10; 這條SQL纹冤，加鎖與組合一：[id主鍵洒宝，Read Committed]一致购公。
與組合五類似，組合六的加鎖雁歌，與組合二：[id唯一索引宏浩，Read Committed]一致。兩個X鎖靠瞎，id唯一索引滿足條件的記錄上一個比庄，對應(yīng)的聚簇索引上的記錄一個。
還記得前面提到的MySQL的四種隔離級別的區(qū)別嗎乏盐？RC隔離級別允許幻讀佳窑，而RR隔離級別，不允許存在幻讀父能。但是在組合五神凑、組合六中，加鎖行為又是與RC下的加鎖行為完全一致何吝。那么RR隔離級別下溉委，如何防止幻讀呢？問題的答案爱榕，就在組合七中揭曉瓣喊。
組合七，Repeatable Read隔離級別呆细，id上有一個非唯一索引，執(zhí)行delete from t1 where id = 10; 假設(shè)選擇id列上的索引進(jìn)行條件過濾八匠，最后的加鎖行為絮爷，是怎么樣的呢？同樣看下面這幅圖：
此圖梨树，相對于組合三：[id列上非唯一鎖坑夯，Read Committed]看似相同，其實卻有很大的區(qū)別抡四。最大的區(qū)別在于柜蜈，這幅圖中多了一個GAP鎖，而且GAP鎖看起來也不是加在記錄上的指巡，倒像是加載兩條記錄之間的位置淑履，GAP鎖有何用？
其實這個多出來的GAP鎖藻雪，就是RR隔離級別秘噪，相對于RC隔離級別，不會出現(xiàn)幻讀的關(guān)鍵勉耀。確實指煎，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ù)不會插入新的滿足條件的記錄并提交俭厚。為了實現(xiàn)這個功能，GAP鎖應(yīng)運(yùn)而生驶臊。
如圖中所示挪挤，有哪些位置可以插入新的滿足條件的項 (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不能插入記錄。因此佑附，通過第一遍的當(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鎖的使用让簿。其實，針對此問題秀睛，還有一個更深入的問題：如果組合五尔当、組合六下，針對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é)束。
組合八绳锅，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原理及實現(xiàn)分析贤姆。
結(jié)論：在Repeatable Read隔離級別下榆苞，如果進(jìn)行全表掃描的當(dāng)前讀，那么會鎖上表中的所有記錄霞捡，同時會鎖上聚簇索引內(nèi)的所有GAP坐漏，杜絕所有的并發(fā) 更新/刪除/插入 操作。當(dāng)然碧信，也可以通過觸發(fā)semi-consistent read赊琳，來緩解加鎖開銷與并發(fā)影響，但是semi-consistent read本身也會帶來其他問題音婶，不建議使用慨畸。
針對前面提到的簡單的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)前讀店印。
寫到這里冈在，其實MySQL的加鎖實現(xiàn)也已經(jīng)介紹的八八九九。只要將本文上面的分析思路按摘，大部分的SQL讥邻，都能分析出其會加哪些鎖。而這里院峡，再來看一個稍微復(fù)雜點的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鎖糊余，加鎖順序為先[1,hdc,100]，后[6,hdc,10]单寂。而Session 2贬芥，從pubtime索引出發(fā)，[10,6],[100,1]均滿足過濾條件宣决，同樣也會加聚簇索引上的記錄X鎖蘸劈，加鎖順序為[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é)，要做的完全掌握MySQL/InnoDB的加鎖規(guī)則屡谐，甚至是其他任何數(shù)據(jù)庫的加鎖規(guī)則述么，需要具備以下的一些知識點：
了解數(shù)據(jù)庫的一些基本理論知識：數(shù)據(jù)的存儲格式 (堆組織表 vs 聚簇索引表)；并發(fā)控制協(xié)議 (MVCC vs Lock-Based CC)愕掏；Two-Phase Locking度秘；數(shù)據(jù)庫的隔離級別定義 (Isolation Level)；
了解SQL本身的執(zhí)行計劃 (主鍵掃描 vs 唯一鍵掃描 vs 范圍掃描 vs 全表掃描)饵撑；
了解數(shù)據(jù)庫本身的一些實現(xiàn)細(xì)節(jié) (過濾條件提冉Ｊ帷唆貌；Index Condition Pushdown；Semi-Consistent Read)垢乙；
了解死鎖產(chǎn)生的原因及分析的方法 (加鎖順序不一致锨咙；分析每個SQL的加鎖順序)
