• my39_InnoDB锁机制之Gap Lock、Next-Key Lock、Record Lock解析


    MySQL InnoDB支持三种行锁定方式:
    行锁(Record Lock):锁直接加在索引记录上面,锁住的是key。
    间隙锁(Gap Lock):
    锁定索引记录间隙,确保索引记录的间隙不变。间隙锁是针对事务隔离级别为可重复读或以上级别而已的。
     
    Next-Key Lock :行锁和间隙锁组合起来就叫Next-Key Lock。
    默认情况下,InnoDB工作在可重复读隔离级别下,并且会以Next-Key Lock的方式对数据行进行加锁,这样可以有效防止幻读的发生。
     
    Next-Key Lock是行锁和间隙锁的组合,当InnoDB扫描索引记录的时候,会首先对索引记录加上行锁(Record Lock),再对索引记录两
    边的间隙加上间隙锁(Gap Lock)。加上间隙锁之后,其他事务就不能在这个间隙修改或者插入记录。
     
    Gap Lock在InnoDB的唯一作用就是防止其他事务的插入操作,以此防止幻读的发生。
     
    行锁(Record Lock)
    行锁锁定的是索引记录,而不是行数据,也就是说锁定的是key。
     
    间隙锁(Gap Lock)
    例如:
    create table test(id int,v1 int,v2 int,primary key(id),key `idx_v1`(`v1`))Engine=InnoDB DEFAULT CHARSET=UTF8;
    insert into test values(1,1,0);
    insert into test values(2,3,1);
    insert into test values(3,4,2);
    insert into test values(5,5,3);
    insert into test values(7,7,4);
    insert into test values(10,9,5);
    该表的记录如下:
    +----+------+------+
    | id | v1 | v2 |
    +----+------+------+
    | 1 | 1 | 0 |
    | 2 | 3 | 1 |
    | 3 | 4 | 2 |
    | 5 | 5 | 3 |
    | 7 | 7 | 4 |
    | 10 | 9 | 5 |
     
    间隙锁(Gap Lock)一般是针对非唯一索引而言的,test表中的v1(非唯一索引)字段值可以划分的区间为:
    (-∞,1)
    (1,3)
    (3,4)
    (4,5)
    (5,7)
    (7,9)
    (9, +∞)
    假如要更新v1=7的数据行,那么此时会在索引idx_v1对应的值,也就是v1的值上加间隙锁,锁定的区间是(5,7)和(7,9)。同时找到
    v1=7的数据行的主键索引和非唯一索引,对key加上锁。
     
    后码锁(Next-Key Lock)
    记录锁和间隙锁的结合,对于InnoDB中,更新非唯一索引对应的记录(在这里来说是更新v1字段的值),会加上Next-Key Lock。如果
    更新记录为空,就不能加记录锁,只能加间隙锁。
     
    以上情况的描述,皆是针对非唯一索引的场景。
    为什么TRANSACTION 2的insert操作会被阻塞,产生等待呢?这是因为TRANSACTION 2插入的v1值为6在TRANSACTION 1的锁定区
    间(5,9)内。而TRANSACTION 1插入的v1值不在TRANSACTION 2的锁定区间(5,7)内,故可以成功插入。不仅仅insert操
    作, update操作也一样会被锁住,从而锁等待超时。
     
    锁选择
    1)、如果更新条件没有走索引,例如执行”update from t1 set v2=0 where v2=5;” ,此时会进行全表扫描,扫表的时候,要阻止其
    他任何的更新操作,所以上升为表锁。
    2)、如果更新条件为索引字段,但是并非唯一索引(包括主键索引),例如执行“update from t1 set v2=0 where v1=9;” 那么此时
    更新会使用Next-Key Lock。使用Next-Key Lock的原因:
    a)、首先要保证在符合条件的记录上加上排他锁,会锁定当前非唯一索引和对应的主键索引的值;
    b)、还要保证锁定的区间不能插入新的数据。
    3)、如果更新条件为唯一索引,则使用Record Lock(记录锁)。
    由此可见,如果可以使用唯一索引的场景,则优先使用唯一索引
    InnoDB根据唯一索引,找到相应记录,将主键索引值和唯一索引值加上记录锁。但不使用Gap Lock(间隙锁)
     
    间隙锁(Gap Lock)
    加后码锁的时候,并没有锁住间隙两端的记录(这里的两端分别是5,9和5,7),那么两端的记录是可以更新的,但是如果更新两端的记录
    会影响到间隙锁,那么操作会被挂起,等待间隙锁释放。
     
    环境
    =============================================================================
    验证1
    ==============================================================================
     
    事务1
    start transaction;
    update test set v2=9 where v1=5;
    事务2
    start transaction;
    update test set v1=3 where v1=4;
    如图片所示,事务不会被挂起
    再分析一下,事务1在非唯一索引上更新,有两个锁:行锁和间隙锁;
    行锁锁定的记录是v1为5的这一行,准确来说是在主键为5的key和v1索引为5的key上加了锁
    间隙锁 锁定了(4,5)、(5,7)这两个间隙,由于字段类型为 整数,也就剩下一个数字6可用
     
    事务2中,对于where条件后面的v1字段,
    对于行锁,只要不为5,就不会与事务1的行锁发生冲突;
    对于gap lock,因为原来就没有6这一行,任何整数值都不会与事务1的gap lock发生冲突;
     
    所以,事务2中会与事务1产生锁冲突的情景只剩下两种:
    更新v1为5的这一行索引字段值
    插入v1为6的数据
    下面再进行一次验证
     
    验证2
    ==============================================================================
    事务1同上
    事务2
    start transaction;
    update test set v1=6 where v1=1;
    事务2处于锁等待状态,结果与预期一致
  • 相关阅读:
    OpenJDK: How to backport patches
    C2 Basis
    大页和透明大页
    Partial Escape Analysis Notes
    C2 Split If
    PrintClassLoaderDataGraphAtExit
    Kubernetes存储(二)
    KubernetesAPI Server
    Kubernetes存储(一)
    Docker多机网络
  • 原文地址:https://www.cnblogs.com/perfei/p/11262449.html
Copyright © 2020-2023  润新知