看如下一條sql語句：

# table T (id int, name varchar(20))

delete from T where id = 10；

MySQL在執行的過程中，是如何加鎖呢？

在看下面這條語句：

select * from T where id = 10；

那這條語句呢？其實這其中包含太多知識點了。要回答這兩個問題，首先需要了解一些知識。

相關知識介紹

多版本并發控制

在MySQL默認存儲引擎InnoDB中，實現的是基于多版本的并發控制協議——MVCC(Multi-Version Concurrency Control)(注：與MVVC相對的，是基于鎖的并發控制，Lock-Based Concurrency Control)。其中MVCC最大的好處是：讀不加鎖，讀寫不沖突。在讀多寫少的OLTP應用中，讀寫不沖突是非常重要的，極大的提高了系統的并發性能，在現階段，幾乎所有的RDBMS，都支持MVCC。其實，MVCC就一句話總結：同一份數據臨時保存多個版本的一種方式，進而實現并發控制。

當前讀和快照讀

在MVCC并發控制中，讀操作可以分為兩類：快照讀與當前讀。

快照讀(簡單的select操作)：讀取的是記錄中的可見版本(可能是歷史版本)，不用加鎖。這你就知道第二個問題的答案了吧。

當前讀(特殊的select操作、insert、delete和update)：讀取的是記錄中最新版本，并且當前讀返回的記錄都會加上鎖，這樣保證了了其他事務不會再并發修改這條記錄。

聚集索引

也叫做聚簇索引。在InnoDB中，數據的組織方式就是聚簇索引：完整的記錄，儲存在主鍵索引中，通過主鍵索引，就可以獲取記錄中所有的列。

最左前綴原則

也就是最左優先，這條原則針對的是組合索引和前綴索引，理解：

1、在MySQL中，進行條件過濾時，是按照向右匹配直到遇到范圍查詢(>, 3 and d = 4 如果建立(a, b, c, d)順序的索引，d是用不到索引的，如果建立(a, b, d, c)索引就都會用上，其中a，b，d的順序可以任意調整。

2、= 和 in 可以亂序，比如 a = 1 and b = 2 and c = 3 建立(a, b, c)索引可以任意順序，MySQL的查詢優化器會優化索引可以識別的形式。

兩階段鎖

傳統的RDMS加鎖的一個原則，就是2PL(Two-Phase Locking，二階段鎖)。也就是說鎖操作分為兩個階段：加鎖階段和解鎖階段，并且保證加鎖階段和解鎖階段不想交。也就是說在一個事務中，不管有多少條增刪改，都是在加鎖階段加鎖，在 commit 后，進入解鎖階段，才會全部解鎖。

隔離級別

MySQL/InnoDB中，定義了四種隔離級別：

Read Uncommitted：可以讀取未提交記錄。此隔離級別不會使用。

Read Committed(RC)：針對當前讀，RC隔離級別保證了對讀取到的記錄加鎖(記錄鎖)，存在幻讀現象。

Repeatable Read(RR)：針對當前讀，RR隔離級別保證對讀取到的記錄加鎖(記錄鎖)，同時保證對讀取的范圍加鎖，新的滿足查詢條件的記錄不能夠插入(間隙鎖)，不存在幻讀現象。

Serializable：從MVCC并發控制退化為基于鎖的并發控制。不區別快照讀和當前讀，所有的讀操作都是當前讀，讀加讀鎖(S鎖)，寫加寫鎖(X鎖)。在該隔離級別下，讀寫沖突，因此并發性能急劇下降，在MySQL/InnoDB中不建議使用。

Gap鎖和Next-Key鎖

在InnoDB中完整行鎖包含三部分：

記錄鎖(Record Lock)：記錄鎖鎖定索引中的一條記錄。

間隙鎖(Gap Lock)：間隙鎖要么鎖住索引記錄中間的值，要么鎖住第一個索引記錄前面的值或最后一個索引記錄后面的值。

Next-Key Lock：Next-Key鎖時索引記錄上的記錄鎖和在記錄之前的間隙鎖的組合。

進行分析

了解完以上的小知識點，我們開始分析第一個問題。當看到這個問題的時候，你可能會毫不猶豫的說，加寫鎖啊。這答案也錯也對，因為已知條件太少。那么有那些需要已知的前提條件呢？

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

前提二：當前系統的隔離級別是什么？

前提三：id列如果不是主鍵，那么id列上有沒有索引呢？

前提四：id列上如果有二級索引，那么是唯一索引嗎？

前提五：SQL執行計劃是什么？索引掃描？還是全表掃描

根據上面的前提條件，可以有九種組合，當然還沒有列舉完全。

id列是主鍵，RC隔離級別

id列是二級唯一索引，RC隔離級別

id列是二級不唯一索引，RC隔離級別

id列上沒有索引，RC隔離級別

d列是主鍵，RR隔離級別

id列是二級唯一索引，RR隔離級別

id列是二級不唯一索引，RR隔離級別

id列上沒有索引，RR隔離級別

組合一：id主鍵 + RC

這個組合是分析最簡單的，到執行該語句時，只需要將主鍵id = 10的記錄加上X鎖。如下圖所示：

結論：id是主鍵是，此SQL語句只需要在id = 10這條記錄上加上X鎖即可。

組合二：id唯一索引 + RC

這個組合，id不是主鍵，而是一個Unique的二級索引鍵值。在RC隔離級別下，是怎么加鎖的呢？看下圖：

由于id是Unique索引，因此delete語句會選擇走id列的索引進行where條件過濾，在找到id = 10的記錄后，首先會將Unique索引上的id = 10的記錄加上X鎖，同時，會根據讀取到的name列，回到主鍵索引(聚簇索引)，然后將聚簇索引上的name = 'e' 對應的主鍵索引項加X鎖。

結論：若id列是Unique列，其上有Unique索引，那么SQL需要加兩個X鎖，一個對應于id Unique索引上的id = 10的記錄，另一把鎖對應于聚簇索引上的(name = 'e', id = 10)的記錄。

組合三：id不唯一索引+RC

該組合中，id列不在唯一，而是個普通索引，那么當執行sql語句時，MySQL又是如何加鎖呢？看下圖：

由上圖可以看出，首先，id列索引上，滿足id = 10查詢的記錄，均加上X鎖。同時，這些記錄對應的主鍵索引上的記錄也加上X鎖。與組合er的唯一區別，組合二最多只有一個滿足條件的記錄，而在組合三中會將所有滿足條件的記錄全部加上鎖。

結論：若id列上有非唯一索引，那么對應的所有滿足SQL查詢條件的記錄，都會加上鎖。同時，這些記錄在主鍵索引上也會加上鎖。

組合四：id無索引+RC

相對于前面的組合，該組合相對特殊，因為id列上無索引，所以在 where id = 10 這個查詢條件下，沒法通過索引來過濾，因此只能全表掃描做過濾。對于該組合，MySQL又會進行怎樣的加鎖呢？看下圖：

由于id列上無索引，因此只能走聚簇索引，進行全表掃描。由圖可以看出滿足條件的記錄只有兩條，但是，聚簇索引上的記錄都會加上X鎖。但在實際操作中，MySQL進行了改進，在進行過濾條件時，發現不滿足條件后，會調用 unlock_row 方法，把不滿足條件的記錄放鎖(違背了2PL原則)。這樣做，保證了最后滿足條件的記錄加上鎖，但是每條記錄的加鎖操作是不能省略的。

結論：若id列上沒有索引，MySQL會走聚簇索引進行全表掃描過濾。由于是在MySQl Server層面進行的。因此每條記錄無論是否滿足條件，都會加上X鎖，但是，為了效率考慮，MySQL在這方面進行了改進，在掃描過程中，若記錄不滿足過濾條件，會進行解鎖操作。同時優化違背了2PL原則。

組合五：id主鍵+RR

該組合為id是主鍵，Repeatable Read隔離級別，針對于上述的SQL語句，加鎖過程和組合一(id主鍵+RC)一致。

組合六：id唯一索引+RR

該組合與組合二的加鎖過程一致。

組合七：id不唯一索引+RR

在組合一到組合四中，隔離級別是Read Committed下，會出現幻讀情況，但是在該組合Repeatable Read級別下，不會出現幻讀情況，這是怎么回事呢？而MySQL又是如何給上述語句加鎖呢？看下圖：

該組合和組合三看起來很相似，但差別很大，在改組合中加入了一個間隙鎖(Gap鎖)。這個Gap鎖就是相對于RC級別下，RR級別下不會出現幻讀情況的關鍵。實質上，Gap鎖不是針對于記錄本身的，而是記錄之間的Gap。所謂幻讀，就是同一事務下，連續進行多次當前讀，且讀取一個范圍內的記錄(包括直接查詢所有記錄結果或者做聚合統計), 發現結果不一致(標準檔案一般指記錄增多, 記錄的減少應該也算是幻讀)。

那么該如何解決這個問題呢？如何保證多次當前讀返回一致的記錄，那么就需要在多個當前讀之間，其他事務不會插入新的滿足條件的記錄并提交。為了實現該結果，Gap鎖就應運而生。

如圖所示，有些位置可以插入新的滿足條件的記錄，考慮到B+樹的有序性，滿足條件的記錄一定是具有連續性的。因此會在 [4, b], [10, c], [10, d], [20, e] 之間加上Gap鎖。

Insert操作時，如insert(10, aa)，首先定位到 [4, b], [10, c]間，然后插入在插入之前，會檢查該Gap是否加鎖了，如果被鎖上了，則Insert不能加入記錄。因此通過第一次當前讀，會把滿足條件的記錄加上X鎖，還會加上三把Gap鎖，將可能插入滿足條件記錄的3個Gap鎖上，保證后續的Insert不能插入新的滿足 id = 10 的記錄，也就解決了幻讀問題。

而在組合五，組合六中，同樣是RR級別，但是不用加上Gap鎖，在組合五中id是主鍵，組合六中id是Unique鍵，都能保證唯一性。一個等值查詢，最多只能返回一條滿足條件的記錄，而且新的相同取值的記錄是無法插入的。

結論：在RR隔離級別下，id列上有非唯一索引，對于上述的SQL語句；首先，通過id索引定位到第一條滿足條件的記錄，給記錄加上X鎖，并且給Gap加上Gap鎖，然后在主鍵聚簇索引上滿足相同條件的記錄加上X鎖，然后返回；之后讀取下一條記錄重復進行。直至第一條出現不滿足條件的記錄，此時，不需要給記錄加上X鎖，但是需要給Gap加上Gap鎖嗎，最后返回結果。

組合八：id無索引+RR

該組合中，id列上無索引，只能進行全表掃描，那么該如何加鎖，看下圖：

如圖，可以看出這是一個很恐怖的事情，全表每條記錄要加X鎖，每個Gap加上Gap鎖，如果表上存在大量數據時，又是什么情景呢？這種情況下，這個表，除了不加鎖的快照讀，其他任何加鎖的并發SQL，均不能執行，不能更新，刪除，插入，這樣，全表鎖死。

當然，和組合四一樣，MySQL進行了優化，就是semi-consistent read。semi-consistent read開啟的情況下，對于不滿足條件的記錄，MySQL會提前放鎖，同時Gap鎖也會釋放。而semi-consistent read是如何觸發：要么在Read Committed隔離級別下；要么在Repeatable Read隔離級別下，設置了 innodb_locks_unsafe_for_binlog 參數。

結論：在Repeatable Read隔離級別下，如果進行全表掃描的當前讀，那么會鎖上表上的所有記錄，并且所有的Gap加上Gap鎖，杜絕所有的 delete/update/insert 操作。當然在MySQL中，可以觸發 semi-consistent read來緩解鎖開銷與并發影響，但是semi-consistent read本身也會帶來其他的問題，不建議使用。

組合九：Serializable

在最后組合中，對于上訴的刪除SQL語句，加鎖過程和組合八一致。但是，對于查詢語句(比如select * from T1 where id = 10)來說，在RC，RR隔離級別下，都是快照讀，不加鎖。在Serializable隔離級別下，無論是查詢語句也會加鎖，也就是說快照讀不存在了，MVCC降級為Lock-Based CC。

結論：在MySQL/InnoDB中，所謂的讀不加鎖，并不適用于所有的情況，而是和隔離級別有關。在Serializable隔離級別下，所有的操作都會加鎖。

一條簡單的刪除語句加鎖情況也就分析完成了，但是學習不止于此，還在繼續，對于復雜SQL語句又是如何加鎖的呢？MySQL中的索引的分析又是怎樣的呢？性能分析、性能優化這些又是怎么呢？還需要進一步的學習探索

總結

以上是生活随笔為你收集整理的mysql执行一条语句会加锁吗_一条简单的更新语句，MySQL是如何加锁的？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。