MySQL死锁深入分析.pdf

abc

126

8页

6次

2024-02-01

免费下载

死锁问题背景 1

1.1 一个不可思议的死锁 1

1.1.1

初步分析

1.2 如何阅读死锁日志 3

2 死锁原因深入剖析 4

2.1 Delete 操作的加锁逻辑 4

2.2 死锁预防策略 5

2.3 剖析死锁的成因 6

3 总结 7

1. 死锁问题背景

做 MySQL 代码的深入分析也有些年头了，再加上自己 10 年左右的数据库内核研发经验，自认为对于

MySQL/InnoDB 的加锁实现了如指掌，正因如此，前段时间，还专门写了一篇洋洋洒洒的文章，专门分

析 MySQL 的加锁实现细节：《MySQL 加锁处理分析》。

但是，昨天”润洁”同学在《MySQL 加锁处理分析》这篇博文下咨询的一个 MySQL 的死锁场景，还是彻底

把我给难住了。此死锁，完全违背了本人原有的锁知识体系，让我百思不得其解。本着机器不会骗人，既

然报出死锁，那么就一定存在死锁的原则，我又重新深入分析了 InnoDB 对应的源码实现，进行多次实验，

配合恰到好处的灵光一现，还真让我分析出了这个死锁产生的原因。这篇博文的余下部分的内容安排，首

先是给出”润洁”同学描述的死锁场景，然后再给出我的剖析。对个人来说，这是一篇十分有必要的总结，

对此博文的读者来说，希望以后碰到类似的死锁问题时，能够明确死锁的原因所在。

1. 一个不可思议的死锁

“润洁”同学，给出的死锁场景如下：

表结构：

CREATE TABLE dltask (

id bigint unsigned NOT NULL AUTO_INCREMENT COMMENT ‘auto id’,

a varchar(30) NOT NULL COMMENT ‘uniq.a’,

b varchar(30) NOT NULL COMMENT ‘uniq.b’,

c varchar(30) NOT NULL COMMENT ‘uniq.c’,

x varchar(30) NOT NULL COMMENT ‘data’,

PRIMARY KEY (id),

UNIQUE KEY uniq_a_b_c (a, b, c)

) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT=’deadlock test';

a，b，c 三列，组合成一个唯一索引，主键索引为 id 列。

事务隔离级别：

RR (Repeatable Read)

每个事务只有一条 SQL：

delete from dltask where a=? and b=? and c=?;

SQL 的执行计划：

死锁日志：

of 8

免费下载

mysql

关注

评论