912
大家好，我是小林。
周末的時候，一個讀者問了我一個很有意思的問題，是關(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_locksG; 這條語句，查看事務(wù) C 在加什么鎖的時候?qū)е伦枞?/p>
從上面的輸出信息，可以看到事務(wù) C 在加「插入意向鎖」的時候，發(fā)生了阻塞。
插入意向鎖是插入操作才會有的鎖，而事務(wù) C 只是執(zhí)行 update 語句，卻出現(xiàn)了插入意向鎖，從這里也可以證明，事務(wù) C 這條特殊的 update 語句運行的時候，被拆分成了兩個操作，一個是刪除，另一個是插入。
總之，如果 update 語句更新的是普通字段的值，就會對發(fā)生更新的記錄加 X 型記錄鎖。
但是，如果 update 語句更新的是索引的值，那么在運行的時候會被拆分成刪除和插入操作，這時候分析鎖的時候，要從這兩個操作的角度去分析。
完啦！
