• ADADADADAD

    MySQL中InnoDB事务锁阅读锁信息状态的示例分析[ mysql数据库 ]

    mysql数据库 时间:2024-11-26 22:15:08

    作者:文/会员上传

    简介:

    ⒈表结构以及数据⑴locktest2表情况如下:id为主键,a为唯一索引CREATE TABLE `locktest2` ( `id` int(11) NOT NULL, `a` int(11) NOT NULL, `b` varchar(30) NOT NULL DEFAULT

    以下为本文的正文内容,内容仅供参考!本站为公益性网站,复制本文以及下载DOC文档全部免费。

    ⒈表结构以及数据

    locktest2表情况如下:id为主键,a为唯一索引
    CREATE TABLE `locktest2` (
    `id` int(11) NOT NULL,
    `a` int(11) NOT NULL,
    `b` varchar(30) NOT NULL DEFAULT 'xddd',
    PRIMARY KEY (`id`),
    UNIQUE KEY `a` (`a`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4
    表中存在如下数据:
    mysql> select * from locktest2;
    +----+----+------+
    | id | a | b |
    +----+----+------+
    | 3 | 2 | xddd |
    | 9 | 20 | ddd |
    | 12 | 13 | ddd |
    | 19 | 7 | cccc |
    | 20 | 5 | abcd |
    | 21 | 4 | fff |
    +----+----+------+


    ⒉构造所等待

    session1如下:

    session2如下(session2处于了等待状态):


    ⒊输出事务锁状态信息以及字段注解


    TABLE LOCK table `test1`.`locktest2` trx id 4955 lock mode IX
    TABLE LOCK:是一个表锁
    table `test1`.`locktest2`:表锁的表是test1库的locktest2表
    trx id 4955:这个事务的事务id(被这个事务所更新的行,行上面的DB_TRX_ID字段都是4599,这个4599主要是MVCC用来做可见性判断
    lock mode IX:IX锁模式,这个主要是针对多粒度锁,在有表锁时,提前检测冲突

    RECORD LOCKS space id 40 page no 4 n bits 80 index a of table `test1`.`locktest2` trx id 4955 lock_mode X locks gap before rec insert intention waiting
    RECORD LOCKS:记录锁
    space id 40 page no 4 n bits 80:表空间编号为40,表空间页的编号为4,用了80位来表示表示加锁情况(bitmap,假设heap no=2的记录被加锁,则在bitmap的第一个元素被置为1,其他的都为0)
    index a of table `test1`.`locktest2`:锁在test1库locktest2表的a索引上
    lock_mode X locks gap before rec insert intention waiting:锁模式为LOCK_X,锁类型为LOCK_GAP|LOCK_INSERT_INTENTION,这个锁处于等待状态;组合一下这个锁,即为LOCK_X|LOCK_GAP|LOCK_INTENTION|LOCK_WAITING(这些不懂请参考我前面的锁与锁模式的文章

    Record lock, heap no 7 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
    Record lock:记录锁
    heap no 7:这条记录在页的中编号为7
    PHYSICAL RECORD: n_fields 2; compact format; info bits 0:物理记录中有两个字段,行格式为compact;记录信息为未标记为删除
    0: len 4; hex 80000014; asc ;;
    第一个字段:长度4个字节,16进制表示的字段值,为14即十进制的20
    1: len 4; hex 80000009; asc ;;
    第二个字段:长度4个字节,16进制表示的字段值,为9即十进制的9
    注意:上面的两个字段组成了二级索引的记录,即(20,9),索引字段值为20,主键字段为9

    RECORD LOCKS space id 40 page no 3 n bits 80 index PRIMARY of table `test1`.`locktest2` trx id 4954 lock_mode X locks rec but not gap
    Record lock, heap no 3 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
    0: len 4; hex 80000009; asc ;;//主键列的值为9
    1: len 6; hex 000000000f6f; asc o;;//DB_TRX_ID,即4954
    2: len 7; hex d200000167011e; asc g ;;//回滚指针rollback ptr
    3: len 4; hex 80000014; asc ;;//a列的值
    4: len 3; hex 646464; asc ddd;;//b列的值

    ⒋锁等待简单分析(这里我们主要是看锁状态信息,所以这个锁等待简单分析下)

    ⑴session 1通过索引a查找记录(where a between 13 and 20),所以会在对二级索引13加上LOCK_X|LOCK_ORDINARY|LOCK_REC,表示锁住二级索引(7,13]这个区间;对二级索引20加上LOCK_X|LOCK_ORDINARY|LOCK_REC,表示锁住二级索引(13,20]这个区间;对二级索引页的supremun记录加上LOCK_X|LOCK_ORDINARY|LOCK_REC,表示锁住(20,+无穷大)这个区间(至于这个为什么锁住supermum这条记录,因为这是第一条未满足条件的记录);注意这里还会对找到的具体主键记录(其实是表数据行)也会加锁,但这里他对锁等待分析不影响。
    ⑵session insert的唯一键a的值为16,这个插入的范围在(13,20]当中,而这个范围被加上了LOCK_X|LOCK_ORDINARY|LOCK_REC锁,与insert的LOCK_X|LOCK_GAP|LOCK_INSERT_INTENTION冲突,所以insert语句被置为了等待状态,即LOCK_X|LOCK_GAP|LOCK_INSERT_INTENTION/LOCK_WAITTING(这里冲突不清楚请看我前面的锁类型与锁模式冲突矩阵的文章).
    MySQL中InnoDB事务锁阅读锁信息状态的示例分析.docx

    将本文的Word文档下载到电脑

    推荐度:

    下载
    热门标签: innodbmysql