MySQL 死锁套路：走不同的索引更新

Winer 发布于2019-05-22 19:43 / 748人阅读

摘要：前几篇文章介绍了用源码的方式来调试锁相关的信息，这里同样用这个工具来解决一个线上实际的死锁案例，也是我们介绍的第一个两条就造成死锁的情况。

前几篇文章介绍了用源码的方式来调试锁相关的信息，这里同样用这个工具来解决一个线上实际的死锁案例，也是我们介绍的第一个两条 SQL 就造成死锁的情况。因为线上的表结构比较复杂，做了一些简化以后如下

CREATE TABLE `t3` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `a` varchar(5),
  `b` varchar(5),
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_a` (`a`),
  KEY `idx_b` (`b`) 
)

INSERT INTO `t3` (`id`, `a`, `b`) VALUES 
	(1,"1","2");
# sql语句如下

# 事务1：t1
update t3 set b = "" where a = "1";

# 事务2：t2
update t3 set b = "" where b = "2";

两条语句造成死锁的情况用手动的方式比较难复现，我们先来分析一下加锁的过程

第一条语句（通过唯一索引去更新记录）

update t3 set b = "" where a = "1";

整理一下，加了3个X锁，顺序分别是

序号	索引	锁类型
1	uk_a	X
2	PRIMARY	X
3	idx_b	X

第二条语句

update t3 set b = "" where b = "2";

整理一下，加了 3 个 X 锁，顺序分别是

序号	索引	锁类型
1	idx_b	X
2	PRIMARY	X
3	idx_b	X

两条语句从加锁顺序看起来就已经有构成死锁的条件了

手动是比较难模拟的，写个代码并发的去同时执行那两条 SQL 语句，马上就出现死锁了

------------------------
LATEST DETECTED DEADLOCK
------------------------
181102 12:45:05
*** (1) TRANSACTION:
TRANSACTION 50AF, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 376, 2 row lock(s)
MySQL thread id 34, OS thread handle 0x70000d842000, query id 549 localhost 127.0.0.1 root Searching rows for update
update t3 set b = "" where b = "2"
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 67 page no 3 n bits 72 index `PRIMARY` of table `d1`.`t3` trx id 50AF lock_mode X locks rec but not gap waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
 0: len 4; hex 80000001; asc     ;;
 1: len 6; hex 0000000050ae; asc     P ;;
 2: len 7; hex 03000001341003; asc     4  ;;
 3: len 1; hex 31; asc 1;;
 4: len 0; hex ; asc ;;

*** (2) TRANSACTION:
TRANSACTION 50AE, ACTIVE 0 sec updating or deleting
mysql tables in use 1, locked 1
4 lock struct(s), heap size 1248, 3 row lock(s), undo log entries 1
MySQL thread id 35, OS thread handle 0x70000d885000, query id 548 localhost 127.0.0.1 root Updating
update t3 set b = "" where a = "1"
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 67 page no 3 n bits 72 index `PRIMARY` of table `d1`.`t3` trx id 50AE lock_mode X locks rec but not gap
Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
 0: len 4; hex 80000001; asc     ;;
 1: len 6; hex 0000000050ae; asc     P ;;
 2: len 7; hex 03000001341003; asc     4  ;;
 3: len 1; hex 31; asc 1;;
 4: len 0; hex ; asc ;;

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 67 page no 5 n bits 72 index `idx_b` of table `d1`.`t3` trx id 50AE lock_mode X locks rec but not gap waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 1; hex 32; asc 2;;
 1: len 4; hex 80000001; asc     ;;

*** WE ROLL BACK TRANSACTION (1)

分析一下死锁日志

*** (1) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 67 page no 3 n bits 72 index PRIMARY of table d1.t3 trx id 50AF lock_mode X locks rec but not gap waiting

事务2：想获取主键索引的 X 锁

*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 67 page no 3 n bits 72 index PRIMARY of table d1.t3 trx id 50AE lock_mode X locks rec but not gap

事务1：持有主键索引的 X 锁

*** (2) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 67 page no 5 n bits 72 index idx_b of table d1.t3 trx id 50AE lock_mode X locks rec but not gap waiting

事务1：想获取普通索引 idx_b 的 X 锁

与我们分析的完全一致，也与线上的死锁日志一模一样

专线服务 idc机房托管 mysql索引性能的问题索引更新 MySQL 死锁 MySQL死锁

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/6886.html

MySQL 死锁套路：唯一索引 S 锁与 X 锁的爱恨情仇

摘要：上一篇文章介绍了使用调试源码的方式来查看死锁的过程，这篇文章来讲讲一个常见的案例。毫不夸张的说，有一半以上的死锁问题由唯一索引贡献，后面介绍的很多死锁的问题都跟唯一索引有关。上一篇文章介绍了使用调试 MySQL 源码的方式来查看死锁的过程，这篇文章来讲讲一个常见的案例。毫不夸张的说，有一半以上的死锁问题由唯一索引贡献，后面介绍的很多死锁的问题都跟唯一索引有关。这次我们讲一段唯一索引 S ...

Darkgel 2019-05-23 14:32 评论0 收藏0
MySQL 死锁套路：唯一索引下批量插入顺序不一致

摘要：死锁的本质是资源竞争，批量插入如果顺序不一致很容易导致死锁，我们来分析一下这个情况。为了方便演示，把批量插入改写为了多条。死锁的本质是资源竞争，批量插入如果顺序不一致很容易导致死锁，我们来分析一下这个情况。为了方便演示，把批量插入改写为了多条 insert。先来做几个小实验，简化的表结构如下 CREATE TABLE `t1` ( `id` int(11) NOT NULL AUTO_...

toddmark 2019-05-23 17:26 评论0 收藏0
数据库两个神器【索引和锁】

摘要：索引需要占物理和数据空间。本质上就是把键值换算成新的哈希值，根据这个哈希值来定位。，索引列不能参与计算，尽量保持列干净。前言只有光头才能变强索引和锁在数据库中可以说是非常重要的知识点了，在面试中也会经常会被问到的。本文力求简单讲清每个知识点，希望大家看完能有所收获声明：如果没有说明具体的数据库和存储引擎，默认指的是MySQL中的InnoDB存储引擎一、索引在之前，我对索...

DevYK 2019-07-31 18:19 评论0 收藏0
数据库两个神器【索引和锁】

摘要：索引需要占物理和数据空间。本质上就是把键值换算成新的哈希值，根据这个哈希值来定位。，索引列不能参与计算，尽量保持列干净。前言只有光头才能变强索引和锁在数据库中可以说是非常重要的知识点了，在面试中也会经常会被问到的。本文力求简单讲清每个知识点，希望大家看完能有所收获声明：如果没有说明具体的数据库和存储引擎，默认指的是MySQL中的InnoDB存储引擎一、索引在之前，我对索...

Euphoria 2019-07-23 17:47 评论0 收藏0
数据库两个神器【索引和锁】

摘要：索引需要占物理和数据空间。本质上就是把键值换算成新的哈希值，根据这个哈希值来定位。，索引列不能参与计算，尽量保持列干净。前言只有光头才能变强索引和锁在数据库中可以说是非常重要的知识点了，在面试中也会经常会被问到的。本文力求简单讲清每个知识点，希望大家看完能有所收获声明：如果没有说明具体的数据库和存储引擎，默认指的是MySQL中的InnoDB存储引擎一、索引在之前，我对索...

TZLLOG 2019-08-19 10:47 评论0 收藏0