大家好，我是小林。

周末的時候，一個讀者問了我一個很有意思的問題，是關(guān)于 MySQL 中 update 加鎖的問題。

他用下面這張數(shù)據(jù)庫表，做了個 MySQL 實驗的時候。

發(fā)現(xiàn)事務(wù) B 的 update 不會阻塞，而事務(wù) C 的 update 會阻塞，都是對 id = 10 這條記錄進行 update， 為什么一個會阻塞，一個不會阻塞？

首先，我們先來分析下，事務(wù) A 這條 SQL 加了什么鎖。

// 事務(wù) A 
select * from t_person where id < 10 for update;

我直接說結(jié)論，事務(wù) A  加了這三個行級鎖：

• 在 id 為 1 的主鍵索引上，加了 X 型的 next-key 鎖，范圍是 (-∞,1]。意味著，其他事務(wù)無法對 id = 1 的記錄進行刪除和更新操作，同時無法插入 id 小于 1 的新記錄。
• 在 id 為 5 的主鍵索引上，加了 X 型的 next-key 鎖，范圍是 (1, 5]。意味著，其他事務(wù)無法對 id = 5 的記錄進行刪除和更新操作，同時無法插入 id 為 2、3、4 的新記錄。
• 在 id 為 10 的主鍵索引上，加了 X 型的間隙鎖，范圍是 (5, 10)。意味著，其他事務(wù)無法插入 id 為 6、7、8、9 的新紀錄。

PS：如果你不清楚什么是 MySQL 這些行級鎖（記錄鎖、間隙鎖、next-key 鎖），以及不清楚行級鎖的加鎖規(guī)則，強烈建議先看我之前寫的這篇：??MySQL 是怎么加行級鎖的？??，看完后，你回頭看我這篇文章，就會有感覺的了。

事務(wù) B 的 update 語句為什么不會阻塞？

事務(wù) B 的 update 語句是對 id = 10 的行記錄的 name 字段進行更新。

// 事務(wù) B
update t_person set name = "小林" where id = 10;

事務(wù) B 會在 id = 10 的主鍵索引上加 X 型記錄鎖，僅鎖住這一行。因為當我們用唯一索引進行等值查詢的時候，查詢的記錄是「存在」的，在索引樹上定位到這一條記錄后，該記錄的索引中的 next-key 鎖會退化成「記錄鎖」。

事務(wù) A 并沒有對 id = 10 的主鍵索引上加 X 型記錄鎖，而是對 id = 10 的主鍵索引上加 X 型間隙鎖。間隙鎖和記錄鎖之間是沒有互斥關(guān)系的，所以事務(wù) B 的 update 語句不會阻塞。

事務(wù) C 的 update 語句為什么會阻塞？

事務(wù) C 的 update 語句是將 id = 10 的行記錄的 id 更新為 2。

// 事務(wù) C
update t_person set id = 2 where id = 10;

這條 update 很特殊，特殊之處在于更新了主鍵索引。你以為它只是一個更新操作，實際上它在背后執(zhí)行了兩個操作：

• 操作 1：delete from t_person where id = 10;
• 操作 2：insert into t_person (2, 陳某,  30, 廣州市海珠區(qū));

也就是先刪除 id = 10 的記錄，然后再插入 id = 2 的新紀錄。

為什么當 update 語句更新了索引值，會被拆分成刪除和插入操作？

要回答這個問題，我們先要清楚 B+ 樹的特點。

Innodb（MySQL 存儲引擎）在實現(xiàn)索引的時候，采用的數(shù)據(jù)結(jié)構(gòu)是 B+ 樹。B+ 樹是基于二分查找樹演變過來的，所以 B+ 樹在存儲索引的時候，是按順序存儲的，因為這樣才能利用二分查找快速檢索到索引。

現(xiàn)在有一顆這樣的  B+ 樹，可以看到葉子節(jié)點的索引值是從小到大的順序。

假設(shè)這時候需要將索引值為 25 更新為 3，如果直接索引值為 25 的位置上，將值改為 3 的話。

這時候你就會發(fā)現(xiàn)這棵 B+ 樹不滿足順序性了！

所以更新索引的值，不能只是修改一個索引值就完事，而是還要保證更新后的索引值能繼續(xù)滿足  B+ 樹的順序性。

解決的方法就是，先刪除索引值為 25 的節(jié)點，再插入索引值為 3 的節(jié)點，這樣，這顆 B+ 樹才能滿足順序性。

事務(wù) C 的 update  語句具體阻塞在哪個「操作」？

現(xiàn)在我們知道，事務(wù) C 的 update 特殊語句背后執(zhí)行了兩個操作，分別是刪除和插入操作，那具體是阻塞在哪個「操作 」？

「操作 1 」是刪除 id = 10 的記錄，事務(wù) C 是會在 id = 10 的主鍵索引上加 X 型記錄鎖，而事務(wù) A 并沒有對 id = 10 的主鍵索引上加 X 型記錄鎖，而是對 id = 10 的主鍵索引上加 X 型間隙鎖。間隙鎖和記錄鎖之間是沒有互斥關(guān)系的，所以「操作 1 」不會阻塞。

根據(jù)排除法，既然 「操作 1 」不會阻塞，那事務(wù) C 的 update 語句阻塞的原因就是因為 「操作 2」發(fā)生了阻塞。

為什么「操作2」會發(fā)生阻塞呢？

我們先要知道，插入操作什么時候會發(fā)生阻塞：插入語句在插入一條新記錄之前，需要先定位到該記錄在 B+樹的位置，如果插入的位置的下一條記錄的索引上有間隙鎖，此時會生成一個插入意向鎖，然后鎖的狀態(tài)設(shè)置為等待狀態(tài)，現(xiàn)象就是插入語句會被阻塞。

「操作 2」插入的是 id = 2 的新記錄，在主鍵索引的 B+樹定位到插入的位置如下圖。

插入位置的下一條記錄是 id = 5 的記錄，而事務(wù) A 在 id 為 5 的主鍵索引上已經(jīng)加了 X 型的 next-key 鎖，這里面包含了間隙鎖。所以「操作 2」的插入操作會發(fā)生阻塞，這就是事務(wù) C 的 update 語句阻塞的原因。

從這我們也可以知道間隙鎖的作用，就是阻止其他事務(wù)在間隙鎖的范圍內(nèi)插入新記錄，從而避免可重復(fù)讀隔離級別下幻讀的現(xiàn)象。

我們也可以通過 select * from performance_schema.data_locks\G; 這條語句，查看事務(wù) C 在加什么鎖的時候?qū)е伦枞?/p>

從上面的輸出信息，可以看到事務(wù) C 在加「插入意向鎖」的時候，發(fā)生了阻塞。

插入意向鎖是插入操作才會有的鎖，而事務(wù) C 只是執(zhí)行 update 語句，卻出現(xiàn)了插入意向鎖，從這里也可以證明，事務(wù) C 這條特殊的 update 語句運行的時候，被拆分成了兩個操作，一個是刪除，另一個是插入。

總之，如果 update 語句更新的是普通字段的值，就會對發(fā)生更新的記錄加 X 型記錄鎖。

但是，如果 update 語句更新的是索引的值，那么在運行的時候會被拆分成刪除和插入操作，這時候分析鎖的時候，要從這兩個操作的角度去分析。

完啦！

怎么樣，夠不夠細節(jié)？