mysql源码分析书籍_从源码分析 MySQL 死锁问题入门

f8a37cd300489dd1881e33be1b13124f.png

链接:https://juejin.im/post/5ce287326fb9a07ea8039d70

这篇文章主要讲的是如何通过调试 MySQL 源码,知道一条 SQL 真正会拿哪些锁,不再抓虾,瞎猜或者何登成大神没写过的场景就不知道如何处理了

通过好多个深夜艰难的单步调试,终于找到了一个理想的断点,可以看到大部分获取锁的过程

代码在lock0lock.cstatic enum db_err lock_rec_lock()函数中,这个函数会显示,获取锁的过程,以及获取锁成功与否的情况

对于之前何登成大神博客里面的内容(hedengcheng.com/?p=771), 我们来做实验逐个验证(以下介绍的都是在 RC 隔离级别下的实验)

场景1:通过主键进行删除

CREATE TABLE `t1` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(10) NOT NULL DEFAULT '',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB;

delete from t1 where id = 10;
aba4c9867ee8794dfd63c47e6ab24736.png

可以看到,对索引 PRIMARY 加锁,mode = 1027,1027是什么意思呢?1027 = LOCK_REC_NOT_GAP + LOCK_X(非 gap 的记录锁且是 X 锁)

过程如下

5360932d6a7db08990e3c5df066ab89e.png

结论:根据主键 id 去删除数据,且没有其它索引的情况下,此 SQL 只需要在 id = 10 这条记录上对主键索引加 X 锁即可

场景2:通过唯一索引进行删除

表结构做了微调,增加了 name 的唯一索引

构造数据

CREATE TABLE `t2` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(10) NOT NULL DEFAULT '',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_name` (`name`)
) ;
INSERT INTO `t2` (`id`, `name`) VALUES
  (1,'M'),
  (2,'Y'),
  (3,'S'),
  (4,'Q'),
  (5,'L');

测试sql语句

delete from t2 where name = "Y"
518a6951f8f0ab79a217bb58b3732513.png

第二步:

ccafabe4d8eb3c9bf22bd94a4805f090.png

结论:这个过程是先对唯一键 uk_name 加 X 锁,然后再对聚簇索引(主键索引)加 X 锁

过程如下:

b8900cfabb6f499a6f557c80af01d402.png
场景3:通过普通索引进行删除
构造数据

CREATE TABLE `t3` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(10) NOT NULL DEFAULT '',
  PRIMARY KEY (`id`),
  KEY `idx_name` (`name`)
);
INSERT INTO `t3` (`id`, `name`) VALUES
  (1,'N'),
  (2,'G'),
  (3,'I'),
  (4,'N'),
  (5,'X');

测试语句:

delete from t3 where name = "N";
a3fae2e28a68c9988f5c9d1f358fa7fb.png

结论:通过普通索引进行更新时,会对满足条件的所有普通索引加 X 锁,同时会对相关的主键索引加 X 锁

过程如下

6d0d7f23296ae888f9aa4c0d4a44b972.png
场景4:不走索引进行删除

CREATE TABLE `t4` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(10) NOT NULL DEFAULT '',
  PRIMARY KEY (`id`)
)

INSERT INTO `t4` (`id`, `name`) VALUES
  (1,'M'),
  (2,'Y'),
  (3,'S'),
  (4,'Q'),
  (5,'L');
  
delete from t4 where name = "S";
9b553613651f0ae56049a3c41966582c.png
9a17cb8bda3e482a0e315c330797dcbe.png

总共有 5 把 X 锁,剩下的 3 把就不一一放上来了

结论:不走索引进行更新时,sql 会走聚簇索引(主键索引)对全表进行扫描,因此每条记录,无论是否满足条件,都会被加上X锁。还没完... 但是为了效率考量,MySQL做了优化,对于不满足条件的记录,会在判断后放锁,最终持有的,是满足条件的记录上的锁,但是不满足条件的记录上的加锁/放锁动作不会省略。

过程如下

09efff3229949656b455c2dc507cb202.png

6d7948f69ccfbb47832ae735e1acceb6.png

确认过眼神3b045d7035cf06efbbb2a0fadd65f941.png

f28647210b6d6021e892e998a5a4de53.png
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值