?首先我們這里有一個表t，其中的數(shù)據如下圖所示

?

?注意哈 update由于操作的最新的值，所以是當前讀！

?另外一個事務插入 8的時候發(fā)生鎖

而我對id為10的數(shù)據進行更新，卻不會被鎖住

?分析：在執(zhí)行當前讀時，由于id=7不存在，可以理解為在B+樹上找7，因此會經過5和10，因此上了nextKey鎖（5，10]，由于右邊界并不等于7，在等值查詢上退化成間隙鎖（5，10）。

?

?

?當我把語句改為 id=5，此時給唯一索引進行等值查詢，退化為行鎖，因此插入8不會被阻塞！

?

?

?在當前讀下，給非唯一索引加鎖的時候，會掃描到第一個不等于索引的值，因此加鎖為（0，5】，（5，10），注意鎖是加在索引上，因此id上沒被加鎖！！！?

?進行范圍查詢，那么加鎖范圍是多少呢？

插入 8會成功，但是插入10卡住了

?說明加鎖了id=10這一行

?而且id=11能夠成功加鎖，說明mysql用了比較智能的判斷，從而使得語句優(yōu)化成只鎖id=10這一行

?改成查10到12之間的

可以看到只鎖了id=10的?

?

?

可以看到只鎖了兩行！！！

?

這次session A用字段c來判斷，：在第一次用c=10定位記錄的時候，索引c上加了(5,10]這個next-key lock后，由于索引c是非唯一索引，沒有優(yōu)化規(guī)則，也就是說不會蛻變?yōu)樾墟i，因此最終sesion A加的鎖是，索引c上的(5,10] 和(10,15] 這兩個next-key lock。

所以從結果上來看，sesson B要插入（8,8,8)的這個insert語句時就被堵住了。

這里需要掃描到c=15才停止掃描，是合理的，因為InnoDB要掃到c=15，才知道不需要繼續(xù)往后找了。

?

?

可以看到15被鎖住了，20沒有被鎖住（MYsql改進的bug 2018之前存在）

加鎖是（10，15]

?

?id為10可以正常操作，沒有被加鎖