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

?

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

?另外一個(gè)事務(wù)插入 8的時(shí)候發(fā)生鎖

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

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

?

?

?當(dāng)我把語(yǔ)句改為 id=5，此時(shí)給唯一索引進(jìn)行等值查詢(xún)，退化為行鎖，因此插入8不會(huì)被阻塞！

?

?

?在當(dāng)前讀下，給非唯一索引加鎖的時(shí)候，會(huì)掃描到第一個(gè)不等于索引的值，因此加鎖為（0，5】，（5，10），注意鎖是加在索引上，因此id上沒(méi)被加鎖！！！?

?進(jìn)行范圍查詢(xún)，那么加鎖范圍是多少呢？

插入 8會(huì)成功，但是插入10卡住了

?說(shuō)明加鎖了id=10這一行

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

?改成查10到12之間的

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

?

?

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

?

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

所以從結(jié)果上來(lái)看，sesson B要插入（8,8,8)的這個(gè)insert語(yǔ)句時(shí)就被堵住了。

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

?

?

可以看到15被鎖住了，20沒(méi)有被鎖住（MYsql改進(jìn)的bug 2018之前存在）

加鎖是（10，15]

?

?id為10可以正常操作，沒(méi)有被加鎖