关于mysql:MySQL-nextkey-lock-加锁范围总结

42次阅读

共计 1154 个字符,预计需要花费 3 分钟才能阅读完成。

前言

三篇文章别离通过实际操作,介绍了主键、非主键惟一索引、一般索引、一般字段四个方面介绍了加锁的范畴。

本篇文章再做一个总结。

data_locks

select * from performance_schema.data_locks;
LOCK_MODE LOCK_DATA 锁范畴
X,REC_NOT_GAP 15 15 那条数据的行锁
X,GAP 15 15 那条数据之前的间隙,不蕴含 15
X 15 15 那条数据的间隙,蕴含 15
  1. LOCK_MODE = X 是前开后闭区间;
  2. X,GAP 是前开后开区间(间隙锁);
  3. X,REC_NOT_GAP 行锁。

这个独自介绍,是心愿我了解的没有谬误,如果大佬看到了,谬误之处肯定要帮忙斧正进去。

主键索引

  1. 加锁时,会先给表增加意向锁,IX 或 IS;
  2. 加锁是如果是多个范畴,是离开加了多个锁,每个范畴都有锁;(这个能够实际下 id < 20 的状况)
  3. 主键等值查问,数据存在时,会对该主键索引的值加行锁 X,REC_NOT_GAP
  4. 主键等值查问,数据不存在时,会对查问条件主键值所在的间隙增加间隙锁 X,GAP
  5. 主键等值查问,范畴查问时状况则比较复杂:

    1. 8.0.17 版本是前开后闭,而 8.0.18 版本及当前,批改为了 前开后开 区间;
    2. 临界 <= 查问时,8.0.17 会锁住下一个 next-key 的前开后闭区间,而 8.0.18 及当前版本,修复了这个 bug。

非主键惟一索引

  1. 非主键惟一索引等值查问,数据存在,for update 是会在主键加锁的,而 for share 只有在走笼罩索引的状况下,会仅在本人索引上加锁;
  2. 非主键索引等值查问,数据不存在,无论是否索引笼罩,相当于一个范畴查问,仅仅会在非主键索引上加锁,加的还是间隙锁,前开后开区间;
  3. 在非主键惟一索引范畴查问时,不是笼罩索引的时候,会对相应的范畴加前开后闭区间,并且如果存在数据,会对对应的主键加行锁;
  4. 在非主键惟一索引范畴查问时,如果是笼罩索引时,会对所有的后闭区间对应的主键,加行锁;
  5. 在非主键惟一索引加锁时,还是存在 next-key 锁住下一个区间的 bug。

一般索引

  1. 一般索引等值查问,因为不能确定唯一性,所以即便定位到记录,也是会向后查问,直到查问到不为该值的记录,从而锁定该值的区间;
  2. 一般索引的锁也是加载该索引上的,如果波及到存在的记录,会对该主键加行锁;
  3. 一般索引的范畴查问,同样呈现 next-key 查问下一个区间的 bug。

一般字段

一般字段查问,会查问全表,这里锁的话就会锁住主键的所有区间。

总结

通过实际操作,最大的感触就是不能眼高手低,看书也好,看文章也罢,肯定要实际操作。

纸上得来终觉浅。

相干文章

  • https://mp.weixin.qq.com/s/JS2gJHb1qS618TQISxMAAw
  • 看来,MySQL next-key lock 的 bug 并没有被修复!
  • MySQL 加锁范畴三——一般索引和一般字段

正文完
 0