2
一个最不可思议的MySQL死锁分析 - yulibo - 博客园.pdf
5墨值下载
2019/9/26 一个最不可思议的MySQL死锁分析 - yulibo
https://www.cnblogs.com/yulibostu/articles/9844061.html 1/7
一个最不可思议的MySQL死锁分析 - yulibo
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列。
2019/9/26 一个最不可思议的MySQL死锁分析 - yulibo
https://www.cnblogs.com/yulibostu/articles/9844061.html 2/7
事务隔离级别：
RR (Repeatable Read)
每个事务只有一条SQL：
delete from dltask where a=? and b=? and c=?;
SQL的执行计划：
死锁日志：
1. 初步分析
of 7
5墨值下载
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文档的来源（墨天轮），文档链接，文档作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
下载排行榜
评论