死锁案例一

最新推荐文章于 2023-02-06 23:26:35 发布

assasinSteven

最新推荐文章于 2023-02-06 23:26:35 发布

阅读量225

点赞数

分类专栏： MySQL 文章标签： mysql

本文链接：https://blog.csdn.net/assasin0308/article/details/108635028

版权

本文详细分析了在MySQL 5.6中，RR事务隔离级别下，死锁发生的两种情况：一是普通索引环境下的死锁，二是唯一键环境下的死锁。通过具体的案例解析了死锁产生的原因和锁的类型，指出在RC隔离级别和ROW BASE BINLOG模式下可以减少死锁，但唯一键冲突导致的死锁仍难以避免。建议在设计表结构时减少unique索引以降低死锁概率。

摘要由CSDN通过智能技术生成

一、前言

死锁，其实是一个很有意思也很有挑战的技术问题，大概每个 DBA 和部分开发同学都会在工作过程中遇见。关于死锁我会持续写一个系列的案例分析，希望能够对想了解死锁的朋友有所帮助。

二、案例分析

2.1 环境说明

MySQL 5.6 事务隔离级别为 RR。

CREATE TABLE `ty` (
`id`int(11) NOT NULL AUTO_INCREMENT,
`a`int(11) DEFAULT NULL,
`b`int(11) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `idxa` (`a`)
) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=utf8mb4
insert into ty(a,b) values(2,3),(5,4),(6,7);

2.2 测试用例

2.3 死锁日志

------------------------
LATEST DETECTED DEADLOCK
------------------------
2017-09-0922:34:137f78eab82700
*** (1) TRANSACTION:
TRANSACTION 462308399, ACTIVE 33 sec starting index read
mysql tables inuse1, locked 1
LOCK WAIT 2lockstruct(s), heap size 360, 1 row lock(s)
MySQL thread id 3525577, OS thread handle 0x7f896cc4b700, query id 780039657 localhost root updating
deletefrom ty where a=5
*** (1) WAITING FOR THIS LOCK TO