珠海房地产网站建设,北京网站开发制作公司,网站建设需求调研问卷,会昌县城乡规划建设局网站首先我们这里有一个表t#xff0c;其中的数据如下图所示 注意哈 update由于操作的最新的值#xff0c;所以是当前读#xff01; 另外一个事务插入 8的时候发生锁 而我对id为10的数据进行更新#xff0c;却不会被锁住 分析#xff1a;在执行当前读时#xff0c;由于id7不存… 首先我们这里有一个表t其中的数据如下图所示 注意哈 update由于操作的最新的值所以是当前读 另外一个事务插入 8的时候发生锁 而我对id为10的数据进行更新却不会被锁住 分析在执行当前读时由于id7不存在可以理解为在B树上找7因此会经过5和10因此上了nextKey锁510]由于右边界并不等于7在等值查询上退化成间隙锁510。 当我把语句改为 id5此时给唯一索引进行等值查询退化为行锁因此插入8不会被阻塞 在当前读下给非唯一索引加锁的时候会扫描到第一个不等于索引的值因此加锁为05】510注意锁是加在索引上因此id上没被加锁 进行范围查询那么加锁范围是多少呢 插入 8会成功但是插入10卡住了 说明加锁了id10这一行 而且id11能够成功加锁说明mysql用了比较智能的判断从而使得语句优化成只锁id10这一行 改成查10到12之间的 可以看到只锁了id10的 可以看到只锁了两行 这次session A用字段c来判断在第一次用c10定位记录的时候索引c上加了(5,10]这个next-key lock后由于索引c是非唯一索引没有优化规则也就是说不会蜕变为行锁因此最终sesion A加的锁是索引c上的(5,10] 和(10,15] 这两个next-key lock。
所以从结果上来看sesson B要插入8,8,8)的这个insert语句时就被堵住了。
这里需要扫描到c15才停止扫描是合理的因为InnoDB要扫到c15才知道不需要继续往后找了。 可以看到15被锁住了20没有被锁住MYsql改进的bug 2018之前存在
加锁是1015] id为10可以正常操作没有被加锁
