Mysql死锁如何排查：insert on duplicate死锁一次排查分析过程

前言

遇到Mysql死锁问题，我们应该怎么排查分析呢？之前线上出现一个insert on duplicate死锁问题，本文将基于这个死锁问题，分享排查分析过程，希望对大家有帮助。

死锁案发还原

表结构：
CREATE TABLE `song_rank` ( `id` int(11) NOT NULL AUTO_INCREMENT, `songId` int(11) NOT NULL, `weight` int(11) NOT NULL DEFAULT ‘0‘, PRIMARY KEY (`id`), UNIQUE KEY `songId_idx` (`songId`) USING BTREE ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
隔离级别：

mysql> select @@tx_isolation;
+-----------------+
| @@tx_isolation  |
+-----------------+
| REPEATABLE-READ |
+-----------------+
1 row in set, 1 warning (0.00 sec)

数据库版本：

+------------+
| @@version  |
+------------+
| 5.7.21-log |
+------------+
1 row in set (0.00 sec)

关闭自动提交：

mysql> select @@autocommit;
+--------------+
| @@autocommit |
+--------------+
|            1 |
+--------------+
1 row in set (0.00 sec)

mysql> set autocommit=0;
Query OK, 0 rows affected (0.00 sec)

mysql> select @@autocommit;
+--------------+
| @@autocommit |
+--------------+
|            0 |
+--------------+
1 row in set (0.00 sec)

表中的数据：

mysql> select * from song_rank;
+----+--------+--------+
| id | songId | weight |
+----+--------+--------+
|  1 |     10 |     30 |
|  2 |     20 |     30 |
+----+--------+--------+
2 rows in set (0.01 sec)

死锁案发原因：

并发环境下，执行insert into … on duplicate key update…导致死锁

死锁模拟复现：

事务一执行：

mysql> begin;    //第一步
Query OK, 0 rows affected (0.00 sec)

mysql> insert into  song_rank(songId,weight) values(15,100) on duplicate key update  weight=weight+1;  //第二步
Query OK, 1 row affected (0.00 sec)

mysql> rollback;   //第七步
Query OK, 0 rows affected (0.00 sec)

事务二执行：

mysql> begin;   //第三步
Query OK, 0 rows affected (0.00 sec)

mysql> insert into  song_rank(songId,weight) values(16,100) on duplicate key update  weight=weight+1;  //   第四步
Query OK, 1 row affected (40.83 sec)

事务三执行：

mysql> begin;  //第五步
Query OK, 0 rows affected (0.00 sec)

mysql> insert into  song_rank(songId,weight) values(18,100) on duplicate key update  weight=weight+1; //第六步

事务一，事务二，事务三执行：

步骤 事务一 事务二 事务三
第一步 begin;
第二步 insert into song_rank(songId,weight) values(15,100) on duplicate key update weight=weight+1; (Query OK, 1 row affected (0.00 sec) )
第三步 begin;
第四步 insert into song_rank(songId,weight) values(16,100) on duplicate key update weight=weight+1; //被阻塞
第五步 begin;
第六步 insert into song_rank(songId,weight) values(18,100) on duplicate key update weight=weight+1; //被阻塞
第七步 rollback;
结果 Query OK, 1 row affected (40.83 sec) ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

死锁浮出水面：

ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

死锁破案排查分析

遇到死锁问题时，我们应该怎么处理呢？分一下几个步骤

1.查看死锁日志

当数据库发生死锁时，可以通过以下命令获取死锁日志：

show engine innodb status;

上面例子insert on duplicate死锁问题的日志如下：

*** (1) TRANSACTION:
TRANSACTION 27540, ACTIVE 19 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 1
MySQL thread id 23, OS thread handle 14896, query id 582 localhost ::1 root update
insert into  song_rank(songId,weight) values(18,100) on duplicate key update  weight=weight+1
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 116 page no 4 n bits 72 index songId_idx of table `test2`.`song_rank` trx id 27540 lock_mode X
locks gap before rec insert intention waiting
Record lock, heap no 3 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 4; hex 80000014; asc     ;;
 1: len 4; hex 80000002; asc     ;;

*** (2) TRANSACTION:
TRANSACTION 27539, ACTIVE 41 sec inserting, thread declared inside InnoDB 1
mysql tables in use 1, locked 1
4 lock struct(s), heap size 1136, 3 row lock(s), undo log entries 1
MySQL thread id 22, OS thread handle 6976, query id 580 localhost ::1 root update
insert into  song_rank(songId,weight) values(16,100) on duplicate key update  weight=weight+1
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 116 page no 4 n bits 72 index songId_idx of table `test2`.`song_rank` trx id 27539 lock_mode X
locks gap before rec
Record lock, heap no 3 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 4; hex 80000014; asc     ;;
 1: len 4; hex 80000002; asc     ;;

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 116 page no 4 n bits 72 index songId_idx of table `test2`.`song_rank` trx id 27539 lock_mode X
locks gap before rec insert intention waiting
Record lock, heap no 3 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 4; hex 80000014; asc     ;;
 1: len 4; hex 80000002; asc     ;;

2.分析死锁日志

如何分析死锁日志呢? 分享一下我的思路

  • 死锁日志分事务1，事务2拆分
  • 找出发生死锁的SQL
  • 找出事务持有什么锁，都在等待什么锁
  • SQL加锁分析

事务1日志分析

从日志我们可以看到事务1正在执行的SQL为：

insert into  song_rank(songId,weight) values(18,100) on duplicate key update  weight=weight+1

该条语句正在等待索引songId_idx的插入意向排他锁：

lock_mode X locks gap before rec insert intention waiting

事务2日志分析

从日志我们可以看到事务2正在执行的SQL为：

insert into  song_rank(songId,weight) values(16,100) on duplicate key update  weight=weight+1

该语句持有一个索引songId_idx的间隙锁：

lock_mode X locks gap before rec

该条语句正在等待索引songId_idx的插入意向排他锁：

lock_mode X locks gap before rec insert intention waiting

锁相关概念补充（附）：

考虑到有些读者可能对上面insert intention锁等不太熟悉，所以这里这里补一小节锁相关概念。
官方文档

InnoDB 锁类型思维导图：

我们主要介绍一下兼容性以及锁模式类型的锁

1.共享锁与排他锁：

InnoDB 实现了标准的行级锁，包括两种：共享锁（简称 s 锁）、排它锁（简称 x 锁）。

  • 共享锁（S锁）：允许持锁事务读取一行。
  • 排他锁（X锁）：允许持锁事务更新或者删除一行。

如果事务 T1 持有行 r 的 s 锁，那么另一个事务 T2 请求 r 的锁时，会做如下处理：

  • T2 请求 s 锁立即被允许，结果 T1 T2 都持有 r 行的 s 锁
  • T2 请求 x 锁不能被立即允许

如果 T1 持有 r 的 x 锁，那么 T2 请求 r 的 x、s 锁都不能被立即允许，T2 必须等待T1释放 x 锁才可以，因为X锁与任何的锁都不兼容。

2.意向锁

  • 意向共享锁( IS 锁)：事务想要获得一张表中某几行的共享锁
  • 意向排他锁( IX 锁)： 事务想要获得一张表中某几行的排他锁

比如：事务1在表1上加了S锁后，事务2想要更改某行记录，需要添加IX锁，由于不兼容，所以需要等待S锁释放；如果事务1在表1上加了IS锁，事务2添加的IX锁与IS锁兼容，就可以操作，这就实现了更细粒度的加锁。

InnoDB存储引擎中锁的兼容性如下表：

3.记录锁（Record Locks）

  • 记录锁是最简单的行锁，仅仅锁住一行。如：SELECT c1 FROM t WHERE c1 = 10 FOR UPDATE
  • 记录锁永远都是加在索引上的，即使一个表没有索引，InnoDB也会隐式的创建一个索引，并使用这个索引实施记录锁。
  • 会阻塞其他事务对其插入、更新、删除

记录锁的事务数据（关键词：lock_mode X locks rec but not gap），记录如下：

RECORD LOCKS space id 58 page no 3 n bits 72 index `PRIMARY` of table `test`.`t`
trx id 10078 lock_mode X locks rec but not gap
Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 4; hex 8000000a; asc     ;;
 1: len 6; hex 00000000274f; asc     'O;;
 2: len 7; hex b60000019d0110; asc        ;;

4.间隙锁（Gap Locks）

  • 间隙锁是一种加在两个索引之间的锁，或者加在第一个索引之前，或最后一个索引之后的间隙。
  • 使用间隙锁锁住的是一个区间，而不仅仅是这个区间中的每一条数据。
  • 间隙锁只阻止其他事务插入到间隙中，他们不阻止其他事务在同一个间隙上获得间隙锁，所以 gap x lock 和 gap s lock 有相同的作用。

5.Next-Key Locks

  • Next-key锁是记录锁和间隙锁的组合，它指的是加在某条记录以及这条记录前面间隙上的锁。

6.插入意向锁（Insert Intention）

  • 插入意向锁是在插入一行记录操作之前设置的一种间隙锁，这个锁释放了一种插入方式的信号，亦即多个事务在相同的索引间隙插入时如果不是插入间隙中相同的位置就不需要互相等待。
  • 假设有索引值4、7，几个不同的事务准备插入5、6，每个锁都在获得插入行的独占锁之前用插入意向锁各自锁住了4、7之间的间隙，但是不阻塞对方因为插入行不冲突。

事务数据类似于下面：

RECORD LOCKS space id 31 page no 3 n bits 72 index `PRIMARY` of table `test`.`child`
trx id 8731 lock_mode X locks gap before rec insert intention waiting
Record lock, heap no 3 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 4; hex 80000066; asc    f;;
 1: len 6; hex 000000002215; asc     " ;;
 2: len 7; hex 9000000172011c; asc     r  ;;...

SQL加锁分析：

通过分析死锁日志，我们可以找到发生死锁的SQL，以及相关等待的锁，我们再对对应的SQL进行加锁分析，其实问题就迎刃而解了。

OK，我们回到对应的SQL，insert into song_rank(songId,weight) values(16,100) on duplicate key update weight=weight+1 执行过程到底加了什么锁呢？加锁机制官方文档

insert加锁策略：

insert语句会对插入的这条记录加排他记录锁，在加记录锁之前还会加一种 GAP 锁，叫做插入意向(insert intention)锁，如果出现唯一键冲突，还会加一个共享记录(S)锁。

（SQL加锁分析非常重要，在这里给大家推荐一篇文章，讲的非常好，解决死锁之路 - 常见 SQL 语句的加锁分析)

insert on duplicate key加锁验证

为了验证一下insert on duplicate key加锁情况，我们拿上面demo的事务1和2在走一下流程。
事务1：

mysql> begin;    //第一步
Query OK, 0 rows affected (0.00 sec)

mysql> insert into  song_rank(songId,weight) values(15,100) on duplicate key
update  weight=weight+1;  //第二步
Query OK, 1 row affected (0.00 sec)

事务2（另开窗口）：

mysql> begin;   //第三步
Query OK, 0 rows affected (0.00 sec)

mysql> insert into  song_rank(songId,weight) values(16,100) on duplicate key
update  weight=weight+1;  //   第四步

使用show engine innodb status查看当前锁请求信息，如图：

有图可得：

事务2持有：IX锁（表锁），gap x锁，insert intention lock（在等待事务1的gap锁）

所以，insert on duplicate 执行过程会上这三把锁。

死锁原因分析

回归到本文开头介绍的死锁案发模拟现场(事务1,2,3)以及死锁日志现场,

案发后事务1的锁：

案发后事务2的锁：

案发复原路线：

1.首先，执行事务1执行:
begin;
insert into song_rank(songId,weight) values(15,100) on duplicate key update weight=weight+1;
会获得 gap锁（10,20），insert intention lock（插入意向锁）

2.接着，事务2执行:
begin;
insert into song_rank(songId,weight) values(16,100) on duplicate key update weight=weight+1;
会获得 gap锁（10,20），同时等待事务1的insert intention lock（插入意向锁）。

3.再然后，事务3执行：
begin;
insert into song_rank(songId,weight) values(18,100) on duplicate key update weight=weight+1;
会获得 gap锁（10,20），同时等待事务1的insert intention lock（插入意向锁）。

4.最后，事务1回滚（rollback），释放插入意向锁，导致事务2,3同时持有gap锁，等待insert intention锁，死锁形成！

锁模式兼容矩阵（横向是已持有锁，纵向是正在请求的锁）：

这是MySql5.7的一个bug

如何避免该insert on duplicate死锁问题

1.把insert on duplicate改为insert

   try{
       insert();
   }catch(DuplicateKeyException e){
       update();
   }

因为insert不会加gap锁，所以可以避免该问题。

2.更改MySql版本

既然这是MySql5.7的一个bug，那么可以考虑更改Mysql版本。

3.尽量减少使用unique index。

gap锁跟索引有关，并且unique key 和foreign key会引起额外的index检查，需要更大的开销，所以我们尽量减少使用不必要的索引。

本文总结（重要）

本文介绍了MySql5.7死锁的一个bug。我们应该怎样去排查死锁问题呢？

  • 1.show engine innodb status;查看死锁日志
  • 2.找出死锁SQL
  • 3.SQL加锁分析
  • 4.分析死锁日志（持有什么锁，等待什么锁）
  • 5.熟悉锁模式兼容矩阵，InnoDB存储引擎中锁的兼容性矩阵。

参考与感谢

个人公众号

  • 如果你是个爱学习的好孩子，可以关注我公众号，一起学习讨论。
  • 如果你觉得本文有哪些不正确的地方，可以评论，也可以关注我公众号，私聊我，大家一起学习进步哈。

原文地址：https://www.cnblogs.com/jay-huaxiao/p/11456921.html

时间： 2024-10-10 23:17:54

Mysql死锁如何排查：insert on duplicate死锁一次排查分析过程的相关文章

INSERT ... ON DUPLICATE KEY UPDATE Syntax

If you specify ON DUPLICATE KEY UPDATE, and a row is inserted that would cause a duplicate value in a UNIQUE index or PRIMARY KEY, MySQL performs an UPDATE of the old row. For example, if column a is declared as UNIQUE and contains the value 1, the f

MYSQL之REPLACE INTO和INSERT … ON DUPLICATE KEY UPDATE用法

REPLACE INTO的用法与INSERT很相似,最终在表中的目的是插入一行新的数据.不同的是,当插入时出现主键或者唯一索引冲突的时候,会删除原有记录,重新插入新的记录.因此,除非表具有主键或者唯一索引,否则使用REPLACE INTO无任何意义. 以下新建了一个表来进行测试,并添加触发检视REPLACE INTO是如何工作的: CREATE TABLE `replace_into` ( `id` int(11) NOT NULL AUTO_INCREMENT, `uid` int(11) N

MySQL INSERT ON DUPLICATE KEY UPDATE

来源:https://www.mysqltutorial.org/mysql-insert-or-update-on-duplicate-key-update/ Introduction to the MySQL INSERT ON DUPLICATE KEY UPDATE statement The INSERT ON DUPLICATE KEY UPDATE is a MySQL's extension to the SQL standard's INSERT statement. When

解决MySQL复合主键下ON DUPLICATE KEY UPDATE语句失效问题

先描述一下这个问题的起因,假设有一张表,里面保存了交易订单,每张订单有唯一的ID,有最后更新时间,还有数据,详情如下: +-------+----------+------+-----+---------------------+-------+ | Field | Type     | Null | Key | Default             | Extra | +-------+----------+------+-----+---------------------+-------

mysql IntegrityError: (pymysql.err.IntegrityError) (1062, "Duplicate entry '000001.SZ-2018-07-02' for key 'PRIMARY'")

IntegrityError: (pymysql.err.IntegrityError) (1062, "Duplicate entry '000001.SZ-2018-07-02' for key 'PRIMARY'")[SQL: INSERT INTO stock_daily_basic (ts_code, trade_date, close, turnover_rate, turnover_rate_f, volume_ratio, pe, pe_ttm, pb, ps, ps_

根据MySQL表数据导出INSERT INTO语句的方法

因项目中有需要需根据MySQL表数据生成INSERT INTO语句,在网上找了些现成的代码,原作者是谁就不知道了,但是发现有BUG,不能适用,遂对他人代码进行了修改.修改后能较好的导出INSERT INTO语句.代码如下: package dwz.interaction; import java.io.*; import java.sql.*; import java.util.ArrayList; import java.util.List; /** * Update by internetr

多线程死锁的产生以及如何避免死锁

一.死锁的定义 多线程以及多进程改善了系统资源的利用率并提高了系统 的处理能力.然而,并发执行也带来了新的问题--死锁.所谓死锁是指多个线程因竞争资源而造成的一种僵局(互相等待),若无外力作用,这些进程都将无法向前推进. 下面我们通过一些实例来说明死锁现象. 先看生活中的一个实例,2个人一起吃饭但是只有一双筷子,2人轮流吃(同时拥有2只筷子才能吃).某一个时候,一个拿了左筷子,一人拿了右筷子,2个人都同时占用一个资源,等待另一个资源,这个时候甲在等待乙吃完并释放它占有的筷子,同理,乙也在等待甲吃

死锁与活锁的区别，死锁与饥饿的区别

第一次玩属于自己的博客,今天在一个App上看到的,说的很好,再敲了一遍,分享一下有关于死锁.活锁及饥饿的概念和区别,希望大家共同进步! 死锁:是指两个或两个以上的进程(或线程)在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力作用,它们都将无法推进下去.此时称系统处于死锁状态或系统产生了死锁,这些永远在互相等待的进程称为死锁进程.死锁发生的四个条件1.互斥条件:线程对资源的访问是排他性的,如果一个线程对占用了某资源,那么其他线程必须处于等待状态,直到资源被释放.2.请求和保持条件:线程

mysql插入数据报错IntegrityError: (1062, "Duplicate entry 'xx' for key 'xxxxx'")

1.问题描述 MySQL插入数据的时候报错,提示如下: IntegrityError: (1062, "Duplicate entry 'xx' for key 'xxxxx'")2.问题分析 根据错误提示我们可以大致得到以下信息: 1.IntegrityError表示这个字段在MySQL中的类型为:整型. 2.Duplicate Entry:“Duplicate”——something that is an exact copy  of something else.所以这句话的意思