MySQL 加鎖處理分析

12月 13th, 2013

發(fā)表評(píng)論 | Trackback

1 背景 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 一條簡(jiǎn)單SQL的加鎖實(shí)現(xiàn)分析 5

2.1 組合一：id主鍵+RC 6

2.2 組合二：id唯一索引+RC 6

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

2.4 組合四：id無(wú)索引+RC 8

2.5 組合五：id主鍵+RR 9

2.6 組合六：id唯一索引+RR 9

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

2.8 組合八：id無(wú)索引+RR 11

2.9 組合九：Serializable 12

3 一條復(fù)雜的SQL 12

4 死鎖原理與分析 14

5 總結(jié) 16

1. 背景

MySQL/InnoDB的加鎖分析，一直是一個(gè)比較困難的話題牢贸。我在工作過(guò)程中，經(jīng)常會(huì)有同事咨詢(xún)這方面的問(wèn)題鹅搪。同時(shí)赚抡，微博上也經(jīng)常會(huì)收到MySQL鎖相關(guān)的私信，讓我?guī)椭鉀Q一些死鎖的問(wèn)題阳仔。本文攒霹，準(zhǔn)備就MySQL/InnoDB的加鎖問(wèn)題怯疤，展開(kāi)較為深入的分析與討論，主要是介紹一種思路剔蹋，運(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ū)別。

1. 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最大的好處滤淳，相信也是耳熟能詳：讀不加鎖，讀寫(xiě)不沖突砌左。在讀多寫(xiě)少的OLTP應(yīng)用中脖咐，讀寫(xiě)不沖突是非常重要的，極大的增加了系統(tǒng)的并發(fā)性能汇歹，這也是為什么現(xiàn)階段屁擅，幾乎所有的RDBMS，都支持了MVCC产弹。

在MVCC并發(fā)控制中愈腾，讀操作可以分成兩類(lèi)：快照讀 (snapshot read)與當(dāng)前讀 (current read)荐捻『瞿酰快照讀，讀取的是記錄的可見(jiàn)版本 (有可能是歷史版本)常挚，不用加鎖作谭。當(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í)行流程：

image.png

從圖中兔乞，可以看到，一個(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)求咱娶，更新這條記錄米间。一條記錄操作完成，再讀取下一條記錄膘侮，直至沒(méi)有滿足條件的記錄為止屈糊。因此，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操作药有；然后在讀取下一條加鎖，直至讀取完畢苹丸。

1. 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è)名稱(chēng)，會(huì)有一些混用忿晕，望讀者知曉装诡。

1. 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)。

image.png

1. 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ì)讀取的范圍加鎖，新的滿足查詢(xún)條件的記錄不能夠插入 (間隙鎖)翠胰，不存在幻讀現(xiàn)象容贝。

• Serializable

  從MVCC并發(fā)控制退化為基于鎖的并發(fā)控制。不區(qū)別快照讀與當(dāng)前讀之景，所有的讀操作均為當(dāng)前讀斤富，讀加讀鎖 (S鎖)，寫(xiě)加寫(xiě)鎖 (X鎖)锻狗。

  Serializable隔離級(jí)別下满力，讀寫(xiě)沖突，因此并發(fā)度急劇下降轻纪，在MySQL/InnoDB下不建議使用油额。

1. 一條簡(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的記錄加寫(xiě)鎖 (走主鍵索引)。

這個(gè)答案對(duì)嗎摹芙？說(shuō)不上來(lái)灼狰。即可能是正確的，也有可能是錯(cuò)誤的浮禾，已知條件不足交胚，這個(gè)問(wèn)題沒(méi)有答案份汗。如果讓我來(lái)回答這個(gè)問(wèn)題，我必須還要知道以下的一些前提蝴簇，前提不同杯活，我能給出的答案也就不同。要回答這個(gè)問(wèn)題熬词，還缺少哪些前提條件旁钧？

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

• 前提二：當(dāng)前系統(tǒng)的隔離級(jí)別是什么互拾？

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

• 前提四：id列上如果有二級(jí)索引颜矿，那么這個(gè)索引是唯一索引嗎寄猩？

• 前提五：兩個(gè)SQL的執(zhí)行計(jì)劃是什么？索引掃描或衡？全表掃描焦影？

沒(méi)有這些前提，直接就給定一條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列上沒(méi)有索引合陵，RC隔離級(jí)別

• 組合五：id列是主鍵枢赔，RR隔離級(jí)別

• 組合六：id列是二級(jí)唯一索引，RR隔離級(jí)別

• 組合七：id列是二級(jí)非唯一索引拥知，RR隔離級(jí)別

• 組合八：id列上沒(méi)有索引踏拜，RR隔離級(jí)別

• 組合九：Serializable隔離級(jí)別

排列組合還沒(méi)有列舉完全，但是看起來(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操作的加鎖狈孔。

1. 組合一：id主鍵+RC

這個(gè)組合信认，是最簡(jiǎn)單，最容易分析的組合均抽。id是主鍵嫁赏，Read Committed隔離級(jí)別，給定SQL：delete from t1 where id = 10; 只需要將主鍵上油挥，id = 10的記錄加上X鎖即可潦蝇。如下圖所示：

image.png

結(jié)論：id是主鍵時(shí)，此SQL只需要在id=10這條記錄上加X(jué)鎖即可喘漏。

組合二：id唯一索引+RC
這個(gè)組合护蝶，id不是主鍵，而是一個(gè)Unique的二級(jí)索引鍵值翩迈。那么在RC隔離級(jí)別下持灰，delete from t1 where id = 10; 需要加什么鎖呢？見(jiàn)下圖：

image.png

此組合中负饲，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(jué)鎖。為什么聚簇索引上的記錄也要加鎖侧漓？試想一下锅尘，如果并發(fā)的一個(gè)SQL，是通過(guò)主鍵索引來(lái)更新：update t1 set id = 100 where name = ‘d’; 此時(shí)布蔗，如果delete語(yǔ)句沒(méi)有將主鍵索引上的記錄加鎖藤违，那么并發(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ì)持有哪些鎖鳄炉？同樣見(jiàn)下圖：

image.png

根據(jù)此圖，可以看到搜骡，首先拂盯，id列索引上，滿足id = 10查詢(xún)條件的記錄记靡，均已加鎖谈竿。同時(shí)团驱，這些記錄對(duì)應(yīng)的主鍵索引上的記錄也都加上了鎖。與組合二唯一的區(qū)別在于空凸，組合二最多只有一個(gè)滿足等值查詢(xún)的記錄嚎花，而組合三會(huì)將所有滿足查詢(xún)條件的記錄都加鎖。

結(jié)論：若id列上有非唯一索引呀洲，那么對(duì)應(yīng)的所有滿足SQL查詢(xún)條件的記錄紊选，都會(huì)被加鎖。同時(shí)道逗，這些記錄在主鍵索引上的記錄兵罢，也會(huì)被加鎖。

組合四：id無(wú)索引+RC
相對(duì)于前面三個(gè)組合憔辫，這是一個(gè)比較特殊的情況趣些。id列上沒(méi)有索引，where id = 10;這個(gè)過(guò)濾條件贰您，沒(méi)法通過(guò)索引進(jìn)行過(guò)濾坏平，那么只能走全表掃描做過(guò)濾。對(duì)應(yīng)于這個(gè)組合锦亦，SQL會(huì)加什么鎖舶替？或者是換句話說(shuō)，全表掃描時(shí)杠园，會(huì)加什么鎖顾瞪？這個(gè)答案也有很多：有人說(shuō)會(huì)在表上加X(jué)鎖；有人說(shuō)會(huì)將聚簇索引上抛蚁，選擇出來(lái)的id = 10;的記錄加上X鎖陈醒。那么實(shí)際情況呢？請(qǐng)看下圖：

image.png

由于id列上沒(méi)有索引瞧甩，因此只能走聚簇索引钉跷，進(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列上沒(méi)有索引兜粘，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的約束。

1. 組合五：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]一致。

1. 組合六：id唯一索引+RR

與組合五類(lèi)似建芙，組合六的加鎖没隘，與組合二：[id唯一索引，Read Committed]一致禁荸。兩個(gè)X鎖右蒲，id唯一索引滿足條件的記錄上一個(gè)，對(duì)應(yīng)的聚簇索引上的記錄一個(gè)赶熟。

1. 組合七：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ò)濾趣苏，最后的加鎖行為狡相，是怎么樣的呢？同樣看下面這幅圖：

image.png

其實(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+樹(shù)索引的有序性沮焕，滿足條件的項(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鎖)钉蒲，與組合三類(lèi)似切端。同時(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è)等值查詢(xún)内地，最多只能返回一條記錄伴澄，而且新的相同取值的記錄，一定不會(huì)在新插入進(jìn)來(lái)阱缓，因此也就避免了GAP鎖的使用非凌。其實(shí)，針對(duì)此問(wèn)題荆针，還有一個(gè)更深入的問(wèn)題：如果組合五敞嗡、組合六下颁糟，針對(duì)SQL：select * from t1 where id = 10 for update; 第一次查詢(xún)，沒(méi)有找到滿足查詢(xún)條件的記錄喉悴，那么GAP鎖是否還能夠省略棱貌？此問(wèn)題留給大家思考。

結(jié)論：Repeatable Read隔離級(jí)別下箕肃，id列上有一個(gè)非唯一索引婚脱，對(duì)應(yīng)SQL：delete from t1 where id = 10; 首先，通過(guò)id索引定位到第一條滿足查詢(xún)條件的記錄勺像，加記錄上的X鎖障贸，加GAP上的GAP鎖，然后加主鍵聚簇索引上的記錄X鎖吟宦，然后返回篮洁；然后讀取下一條，重復(fù)進(jìn)行督函。直至進(jìn)行到第一條不滿足條件的記錄[11,f]嘀粱，此時(shí)，不需要加記錄X鎖辰狡，但是仍舊需要加GAP鎖锋叨，最后返回結(jié)束。

1. 組合八：id無(wú)索引+RR

組合八宛篇，Repeatable Read隔離級(jí)別下的最后一種情況娃磺，id列上沒(méi)有索引。此時(shí)SQL：delete from t1 where id = 10; 沒(méi)有其他的路徑可以選擇叫倍，只能進(jìn)行全表掃描偷卧。最終的加鎖情況，如下圖所示：

image.png

如圖吆倦，這是一個(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]類(lèi)似摊崭，這個(gè)情況下讼油，MySQL也做了一些優(yōu)化，就是所謂的semi-consistent read呢簸。semi-consistent read開(kāi)啟的情況下矮台，對(duì)于不滿足查詢(xún)條件的記錄，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)緩解加鎖開(kāi)銷(xiāo)與并發(fā)影響逗威，但是semi-consistent read本身也會(huì)帶來(lái)其他問(wèn)題峰搪，不建議使用。

1. 組合九：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)前讀茫叭。

1. 一條復(fù)雜的SQL

寫(xiě)到這里酬屉，其實(shí)MySQL的加鎖實(shí)現(xiàn)也已經(jīng)介紹的八八九九。只要將本文上面的分析思路揍愁，大部分的SQL呐萨，都能分析出其會(huì)加哪些鎖。而這里莽囤，再來(lái)看一個(gè)稍微復(fù)雜點(diǎn)的SQL谬擦，用于說(shuō)明MySQL加鎖的另外一個(gè)邏輯。SQL用例如下：

image.png

如圖中的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索引上的查詢(xún)范圍尾抑。

• 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í)別)，如下圖所示：

image.png

結(jié)論：在Repeatable Read隔離級(jí)別下室梅，針對(duì)一個(gè)復(fù)雜的SQL戏仓，首先需要提取其where條件。Index Key確定的范圍亡鼠，需要加上GAP鎖赏殃；Index Filter過(guò)濾條件，視MySQL版本是否支持ICP间涵，若支持ICP仁热，則不滿足Index Filter的記錄，不加X(jué)鎖勾哩，否則需要X鎖抗蠢；Table Filter過(guò)濾條件，無(wú)論是否滿足思劳，都需要加X(jué)鎖迅矛。

1. 死鎖原理與分析

本文前面的部分，基本上已經(jīng)涵蓋了MySQL/InnoDB所有的加鎖規(guī)則潜叛。深入理解MySQL如何加鎖秽褒，有兩個(gè)比較重要的作用：

• 可以根據(jù)MySQL的加鎖規(guī)則，寫(xiě)出不會(huì)發(fā)生死鎖的SQL威兜；

• 可以根據(jù)MySQL的加鎖規(guī)則销斟，定位出線上產(chǎn)生死鎖的原因；

下面椒舵，來(lái)看看兩個(gè)死鎖的例子 (一個(gè)是兩個(gè)Session的兩條SQL產(chǎn)生死鎖票堵；另一個(gè)是兩個(gè)Session的一條SQL，產(chǎn)生死鎖)：

image.png

image.png

上面的兩個(gè)死鎖用例逮栅。第一個(gè)非常好理解悴势，也是最常見(jiàn)的死鎖，每個(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)沒(méi)有哨苛，跟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ā)生的原因音半。

1. 總結(jié)

寫(xiě)到這兒则拷，本文也告一段落，做一個(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)不在話下候衍。

標(biāo)簽: Database, Deadlock, Lock, MySQL

并發(fā)編程系列之一：鎖的意義C/C++ Volatile關(guān)鍵詞深度剖析