记录生产mysql死锁解决过程

这篇具有很好参考价值的文章主要介绍了记录生产mysql死锁解决过程。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

最近生产上每个星期都会有几次死锁告警异常,今天终于给处理了,待后续观察,记录下整个过程。

环境:springboot、mybatis、mysql(RC隔离级别)

表结构:

CREATE TABLE `table1` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `prize_key` varchar(128) ,
  'case_id'
  `in_case_index` int,

  PRIMARY KEY (`id`),
  KEY `idx_case_id` (`case_id`)
);

阿里云日志告警:

### Cause: com.mysql.cj.jdbc.exceptions.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction
; Deadlock found when trying to get lock; try restarting transaction; nested exception is com.mysql.cj.jdbc.exceptions.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction

立刻查找生产mysql死锁日志:

show engine innodb status;

------------------------
LATEST DETECTED DEADLOCK
------------------------
2023-06-26 14:19:21 0x7fb2ddf141ff700
*** (1) TRANSACTION:
TRANSACTION 2221516621, ACTIVE 0 sec fetching rows
mysql tables in use 2, locked 2
LOCK WAIT 676 lock struct(s), heap size 73936, 6770 row lock(s), undo log entries 10
MySQL thread id 14996730, OS thread handle 14040d64831044096, query id 462343171910 10.1.4.1 lottery executing
insert into X
     ( prize_key,
        prize_type,

*** (1) HOLDS THE LOCK(S):
RECORD LOCKS space id 666 page no 864646 n bits 112 index PRIMARY of table `xx`.`table1` trx id 2221516621 lock mode S locks rec but not gap

Record lock, heap no 8 PHYSICAL RECORD: n_fields 33; compact format; info bits 128
 0: len 8; hex 80000000d001bdb6d7; asc         ;;
 1: len 6; hex 00008468599e; asc    hY ;;
 2: len 7; hex 01000003571172; asc     W r;;
 3: len 30; hex 64643332343238332d313032652d1346335652d623131342d633537316663; asc dd324283-102e-4c5e-b114-c571fc; (total 36 bytes);

*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 666 page no 864646 n bits 112 index PRIMARY of table `xx`.`table1` trx id 2221516621 lock mode S locks rec but not gap waiting
Record lock, heap no 42 PHYSICAL RECORD: n_fields 33; compact format; info bits 128
 0: len 8; hex 8000000000bdb6f3; asc         ;;
 1: len 6; hex 00008469a753; asc    i S;;
 2: len 7; hex 020000096b30c4; asc     k0 ;;
 3: len 30; hex 36356265633039662d633136662d3432323112d623063352d353933626362; asc 65bec09f-c16f-4221-b0c5-593bcb; (total 36 bytes);



*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 666 page no 864646 n bits 112 index PRIMARY of table `xx`.`table1` trx id 2221516627 lock_mode X locks rec but not gap
Record lock, heap no 2 PHYSICAL RECORD: n_fields 33; compact format; info bits 128
 0: len 8; hex 8000000000bdb6d1; asc         ;;
 1: len 6; hex 00008469a753; asc    i S;;
 2: len 7; hex 020000096b162a; asc     k *;;
 3: len 30; hex 3038343738306d6322d323362362d3464611652d616333612d313639626136; asc 084780f2-23b6-4dae-ac3a-169ba6; (total 36 bytes);

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 666 page no 864646 n bits 112 index PRIMARY of table `xx`.`table1` trx id 2221516627 lock_mode X locks rec but not gap waiting
Record lock, heap no 33 PHYSICAL RECORD: n_fields 33; compact format; info bits 128
 0: len 8; hex 8000000000bdb6f0; asc         ;;
 1: len 6; hex 000084685661; asc    hVa;;
 2: len 7; hex 81000001350143; asc     5 C;;
 3: len 30; hex 66643332656336622d363536662d343761392d6166139342d333563653634; asc fd32ec6b-656f-47a9-af94-35ce64; (total 36 bytes);

*** WE ROLL BACK TRANSACTION (2)

根据事物1和事物2的sql,以及java报错的堆栈信息,找到发生问题的代码。

大致如下:

// 事物1
for () {
   xxmaper.insert();
}

//事物2
xxmaper.update(list);

大概看了下,俩个事物不会存在插入和修改的数据冲突。

只能查看mysql审计日志了,通过阿里云后台,用MySQL thread id,分别查到 俩个事物所有运行的sql。大致如下:

--事物1:
-- 10个insert
insert into table1
     ( prize_key,prize_type, `case_id`,`in_case_index` ) 
     values ( 'cf2c9336-4bcc-44f8-b57a-e9a020c9e2f3','Z', 11133, (SELECT a.ci+1 from (SELECT IFNULL(MAX( `in_case_index`),0) as ci  FROM `table1` WHERE `case_id` = 111) as a) );

-- 事物2
-- 100多个update
update table1 where prize_key in ('','');

看到最终的sql,有点眉目了,再次查看mysql死锁日志。得到如下结果:

事物1执行到sql,
insert into table1
     ( prize_key,prize_type, `in_case_index` ) 
     values ( '1cf2c9336-4bcc-44f8-b57a-e9a020c9e2f3','Z',
 (SELECT a.ci+1 from (SELECT IFNULL(MAX( `in_case_index`),0) as ci  FROM `table1` WHERE `case_id` = 68033) as a) )
 
拿到s锁: 
HOLDS THE LOCK(S):  666 page no 864646 n bits 112 index PRIMARY of table `xx`.`table1` trx id 2221516621 lock mode S locks rec but not gap
  
具体s锁记录:386fd81cc-4689-4f20-89d1-e98967,fd32ec6b-656f-47a9-af94-35ce64,
 
等待s锁:RECORD LOCKS space id 666 page no 864646 n bits 112 index PRIMARY of table `xx`.`table1` trx id 2221516621 lock mode S locks rec but not gap waiting

具体等待记录:65bec09f-c16f-4221-b0c5-593bcb


事物2:
拿到x锁: HOLDS THE LOCK(S):  RECORD LOCKS space id 666 page no 864646 n bits 112 index PRIMARY of table `xx`.`table1` trx id 2221516627 lock_mode X locks rec but not gap

具体x锁记录:084780f2-23b6-4dae-ac3a-169ba6,,65fee89c-2d22-4abd-a8d1-0d9357

等待X锁:RECORD LOCKS space id 666 page no 864646 n bits 112 index PRIMARY of table `xx`.`table1` trx id 2221516627 lock_mode X locks rec but not gap waiting

具体等待记录记录:fd32ec6b-656f-47a9-af94-35ce64,
 

说白了,就是:

事物1拿到了S锁,等待S锁; 这个记录被事物2拿到了X锁;

事物2拿到了X锁,等待X锁;这条记录被事物1拿到了S锁;

分析已经很到位了,下面就是本地复现。

将相关sql复制到本地,开两个窗口,关闭自动提交。确实复现了。

最终解决方案:

因为事物1拿到的是s锁,且是主键锁,所以最简单办法就是 select里面,避免去回表。

SELECT a.ci+1 from
      (SELECT IFNULL(MAX( `in_case_index`),0) as ci  FROM `table1` WHERE `case_id` = 1111) as a

执行计划看到的是走的索引idx_case_id。

于是给这个索引加了一个组合,idx_case_id(case_id,in_case_index);

再次走 执行计划,确实没有回表了。

记录生产mysql死锁解决过程

 至此mysql死锁问题解决,后面就是静静的等待结果了,没有结果就是最好的结果。文章来源地址https://www.toymoban.com/news/detail-511415.html

到了这里,关于记录生产mysql死锁解决过程的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • Mysql和Oracle数据库死锁查看以及解决

    一、Mysql数据库死锁排查 SQL : SQL: SQL: 示例: 备注:通过查看事务的trx_started(开始时间)来判断该事务的阻塞时间。 SQL  : 备注:线程ID指的是 1.1.3步骤中查询出来的 trx_mysql_thread_id。 SQL : 示例 : 字段解析 : SQL : 示例: SQL : 备注:多个session用逗号隔开。 View Code   造

    2024年01月20日
    浏览(46)
  • MySQL遇到过死锁问题吗,你是如何解决的?

    MySQL遇到过死锁问题吗,你是如何解决的? 问题解析 死锁,就是两个或者两个以上的线程在执行过程中,去争夺同一个共享资源导致互相等待的现象。 在没有外部干预的情况下,线程会一直处于阻塞状态,无法往下执行。 要想真正产生死锁,必须同时满足四个条件。互斥条

    2024年02月02日
    浏览(51)
  • 【MySQL】数据库排查慢查询、死锁进程排查、预防以及解决方法

    1.1检查慢查询日志是否开启 1.1.1使用命令检查是否开启慢查询日志: 如果是 Value 为 off 则并未开启 1.1.2开启并且查看慢查询日志: MySQL提供了慢查询日志功能,可以记录所有执行时间超过long_query_time秒的查询语句,通过分析这些慢查询可以找到数据库性能瓶颈。 启用慢查询日志

    2024年03月19日
    浏览(91)
  • 【Linux】面试重点:死锁和生产消费模型原理

    面试要点来了~ 文章目录 前言 一、死锁的一系列问题 二、生产者消费者模型原理 总结 上一篇的互斥量原理中我们讲解了锁的原理,我们知道每次线程申请锁的时候一旦申请成功这个线程自己就把锁带在自己身上了,这就保证了锁的原子性(因为只有一个锁),而当我们已经

    2024年02月09日
    浏览(40)
  • MySQL的index merge(索引合并)导致数据库死锁分析与解决方案

    在DBS-集群列表-更多-连接查询-死锁中,看到9月22日有数据库死锁日志,后排查发现是因为mysql的优化-index merge(索引合并)导致数据库死锁。 index merge(索引合并):该数据库查询优化的一种技术,在mysql 5.1之后进行引入,它可以在多个索引上进行查询,并将结果合并返回。 在

    2024年02月08日
    浏览(82)
  • Centos7.6 安装mysql过程全记录

    在centos 7.6上 离线安装mysql 的步骤,可参考下文: 查找之前是否安装了MySQL rpm -qa|grep -i mysql 如果已经安装mysql,则需要先停止MySQL,再删除之前安装的MySQL ,把rpm -qa | grep mysql 得到的安装包名XXX 写上即 rpm -ev xxx  rpm -ev bt-mysql56-5.6.47-1.el7.x86_64 查找之前MySQL的目录,删除老版本

    2024年02月13日
    浏览(39)
  • MySQL8.0.22安装过程记录(个人笔记)

    1.点击下载MySQL 2.解压到本地磁盘(注意路径中不要有中文) 3.在解压目录创建my.ini文件 文件内容为 4.配置环境变量 找到系统变量path,选中编辑再新建,把本地磁盘mysql的bin路径复制进来 5.管理员运行cmd 6.切换到MySQL的安装路径 7.输入初始化命令 注意要记住此时生成的密码

    2024年02月10日
    浏览(44)
  • Mysql5.7大限将至升级Mysql 8.0过程记录(未完)

    时间很快,到2023年10月底,MySQL 5.7就到了它的EOL(End of Life),届时将不会提供任何补丁,无法应对潜在的安全风险;是时候和 MySQL 5.7 说再见了!!!!回顾自Mysql5.7 版本2015年10月发布,它带来很多新的特性,比如:默认引擎改成了InnoDB,更新了安全策略,性能方面的提升,

    2024年01月21日
    浏览(41)
  • 在CentOS上用yum方式安装MySQL8过程记录

    此文参考官方文档一步一步记录安装到正常运行全过程 安装环境:centos7 mysql版本:8.0.35 安装过程主要参考下面两边文章: 1.官方文档 https://dev.mysql.com/doc/refman/8.0/en/linux-installation-yum-repo.html 2.linux yum安装mysql8 安装过程大概有以下几步: 1.查找mysql源链接 2.安装mysql源(仓库)

    2024年02月07日
    浏览(53)
  • STlink无法下载?解决过程记录。

    先分析一波 stlink直接下载失败,要么no target connected,要么internal command error,要么stlink connect error。 设备管理器里,stlink是黑色,运行正常。说明电脑的stlink驱动正常。 按住复位键,下载,1秒松开,下载成功,说明stlink本身没问题。问题在stm32。 IO口接LED,亮度非常微弱

    2024年02月12日
    浏览(54)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包