死锁示例

最新推荐文章于 2022-09-09 16:20:00 发布
最新推荐文章于 2022-09-09 16:20:00 发布
阅读量127 收藏
点赞数
文章标签： php 数据库
原文链接：http://www.cnblogs.com/fanguangdexiaoyuer/p/11252698.html
版权

两个小工具，MySQL死锁分析

多个事务并发执行update出现的数据库死锁问题排除

可以通过SHOW ENGINE INNODB STATUS;来查看死锁日志

死锁日志：

** (1)  TRANSACTION :
TRANSACTION  6648945293, ACTIVE 0 sec starting  index  read
mysql tables  in  use 3, locked 3
LOCK WAIT 5 lock struct(s), heap  size  1184, 4 row lock(s)
MySQL thread id 7953966, OS thread handle 0x7f5b58350700, query id 8422437535 10.129.128.237 promcenter Searching  rows  for  update
update  pc_coupon_0200
         set
         used_time =  null ,
         gmt_modified =  '2017-08-31 00:00:00.841' ,
         status =  'NOT_USED' ,
         trade_no =  null
         where
         code =  '4ab5bf23-d09e-4947-8e83-4e6619c1f750'
         and  user_id = 29096550200
*** (1) WAITING  FOR  THIS LOCK  TO  BE GRANTED:
RECORD LOCKS  space  id 285 page  no  33715 n bits 152  index  ` PRIMARY `  of  table  `promcenter`.`pc_coupon_0200` trx id 6648945293 lock_mode X locks rec but  not  gap waiting
Record lock, heap  no  79 PHYSICAL RECORD: n_fields 22; compact format; info bits 0
  0: len 8; hex 8000000000192b58;  asc        +X;;
  1: len 6; hex 000188c2bcfa;  asc        ;;
  2: len 7; hex 1e00001dd70680;  asc         ;;
  3: len 8; hex 80000000000009e2;  asc          ;;
  4: len 28; hex e696b0e4babae4b893e4baab35e58583e697a0e997a8e6a79be588b8;  asc              5               ;;
  5: len 8; hex 80000006c64a1f38;  asc       J 8;;
  6: SQL  NULL ;
  7: SQL  NULL ;
  8: SQL  NULL ;
  9: len 30; hex 30626430373532632d636638662d346264352d383961302d373064313266;  asc  0bd0752c-cf8f-4bd5-89a0-70d12f; (total 36 bytes);
  10: SQL  NULL ;
  11: len 4; hex 55534544;  asc  USED;;
  12: len 5; hex 999d6e0a7b;  asc    n {;;
  13: len 5; hex 999d795e39;  asc    y^9;;
  14: len 5; hex 999d6e0a7b;  asc    n {;;
  15: len 5; hex 999d8d7efb;  asc     ~ ;;
  16: len 5; hex 999d6e0a7b;  asc    n {;;
  17: len 5; hex 999d795e39;  asc    y^9;;
  18: len 30; hex 66646635363862312d663036632d346232382d383935382d636463316433;  asc  fdf568b1-f06c-4b28-8958-cdc1d3; (total 36 bytes);
  19: len 7; hex 74726964656e74;  asc  trident;;
  20: len 27; hex 75736572696e766974653a32393039363535303230303a32353330;  asc  userinvite:29096550200:2530;;
  21: len 3; hex 414c4c;  asc  ALL ;;
*** (2)  TRANSACTION :
TRANSACTION  6648945294, ACTIVE 0 sec starting  index  read
mysql tables  in  use 3, locked 3
4 lock struct(s), heap  size  1184, 3 row lock(s)
MySQL thread id 7953138, OS thread handle 0x7f5b3e8b7700, query id 8422437534 10.129.129.119 promcenter Searching  rows  for  update
update  pc_coupon_0200
         set
         used_time =  null ,
         gmt_modified =  '2017-08-31 00:00:00.841' ,
         status =  'NOT_USED' ,
         trade_no =  null
         where
         code =  '0bd0752c-cf8f-4bd5-89a0-70d12fd26dd3'
         and  user_id = 29096550200
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS  space  id 285 page  no  33715 n bits 152  index  ` PRIMARY `  of  table  `promcenter`.`pc_coupon_0200` trx id 6648945294 lock_mode X locks rec but  not  gap
Record lock, heap  no  79 PHYSICAL RECORD: n_fields 22; compact format; info bits 0
  0: len 8; hex 8000000000192b58;  asc        +X;;
  1: len 6; hex 000188c2bcfa;  asc        ;;
  2: len 7; hex 1e00001dd70680;  asc         ;;
  3: len 8; hex 80000000000009e2;  asc          ;;
  4: len 28; hex e696b0e4babae4b893e4baab35e58583e697a0e997a8e6a79be588b8;  asc              5               ;;
  5: len 8; hex 80000006c64a1f38;  asc       J 8;;
  6: SQL  NULL ;
  7: SQL  NULL ;
  8: SQL  NULL ;
  9: len 30; hex 30626430373532632d636638662d346264352d383961302d373064313266;  asc  0bd0752c-cf8f-4bd5-89a0-70d12f; (total 36 bytes);
  10: SQL  NULL ;
  11: len 4; hex 55534544;  asc  USED;;
  12: len 5; hex 999d6e0a7b;  asc    n {;;
  13: len 5; hex 999d795e39;  asc    y^9;;
  14: len 5; hex 999d6e0a7b;  asc    n {;;
  15: len 5; hex 999d8d7efb;  asc     ~ ;;
  16: len 5; hex 999d6e0a7b;  asc    n {;;
  17: len 5; hex 999d795e39;  asc    y^9;;
  18: len 30; hex 66646635363862312d663036632d346232382d383935382d636463316433;  asc  fdf568b1-f06c-4b28-8958-cdc1d3; (total 36 bytes);
  19: len 7; hex 74726964656e74;  asc  trident;;
  20: len 27; hex 75736572696e766974653a32393039363535303230303a32353330;  asc  userinvite:29096550200:2530;;
  21: len 3; hex 414c4c;  asc  ALL ;;
*** (2) WAITING  FOR  THIS LOCK  TO  BE GRANTED:
RECORD LOCKS  space  id 285 page  no  33489 n bits 792  index  `ix_user_id`  of  table  `promcenter`.`pc_coupon_0200` trx id 6648945294 lock_mode X locks rec but  not  gap waiting
Record lock, heap  no  342 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
  0: len 8; hex 80000006c64a1f38;  asc       J 8;;
  1: len 8; hex 8000000000192b58;  asc        +X;;
*** WE ROLL BACK  TRANSACTION  (2)
 

mysql 事务具有acid属性，分别是代表原子性，隔离性，一致性，持久性。

根据原子性可以知道事务操作是不可再分的，每个事务要么全部成功要么全部失败，通过隔离性可以知道：事务之间不会相互影响。

但是本次为什么还出现了并发事务出现了死锁问题呢？

 

根据死锁日志可以提取几个有用信息：

 
trx1（事务1）
trx2（事务2）
id66489452936648945294
特征活跃0秒，正在index读活跃0秒，正在index读
原因Searching rows for updateSearching rows for update
sql

update pc_coupon_0200
set
used_time = null,
gmt_modified = '2017-08-31 00:00:00.841',
status = 'NOT_USED',
trade_no = null
where
code = '4ab5bf23-d09e-4947-8e83-4e6619c1f750'
and user_id = 29096550200

update pc_coupon_0200
set
used_time = null,
gmt_modified = '2017-08-31 00:00:00.841',
status = 'NOT_USED',
trade_no = null
where
code = '0bd0752c-cf8f-4bd5-89a0-70d12fd26dd3'
and user_id = 29096550200

锁定行数43

正在等待的锁特性/

正在持有锁特性

等待：{聚集索引id：285，页码：33715，锁类型：排他锁，非GAP(间隙)锁，

事务号：6648945293，索引：主键索引}

 

持有：idx_user_id的锁

持有：{锁id：285，页码：33715，锁类型：共享锁，非GAP(间隙)锁，

事务号：6648945293，索引：主键索引}

等待：

{聚集索引id：285，页码：33489，锁类型：排他锁，非GAP(间隙)锁，

事务号：6648945293，索引：idx_user_id}

是否回滚否  是

首先mysql默认的隔离级别是可重复读，事务未提交之前总是读到相同的记录，该隔离级别就是为了避免读已提交出现的幻读现象，采用的是GAP间隙锁实现。

根据上表可以得到信息，两个事务都未提交，或者说行锁锁定的记录之外没有其他事务提交的与之有关的记录，所以都未用到gap锁，有点绕。。。

根据日志可以发现update语句其实就是select xxx for update，这个语句会持有排他锁（共享锁是in share mode）。

事务1等待排他锁，事务2持有事务1的共享锁，并且等待排他锁。这样就能死锁了？？为什么事务1没有持有事务2的共享锁

mysql官方有个bug帖子，如下：

https://bugs.mysql.com/bug.php?id=77209

建议：

Do not use index merge when single index is good enough
Try to avoid using index merge in UPDATE to not provoke deadlocks

 

所以在写sql的时候能用一个索引尽量不要使用两个混合索引去更新，可以先根据索引查询出结果，再执行更新。

 

另：

解决方案

  1. 使用组合索引(a+b)
  2. 关闭index merge优化器

mysql innodb行级锁的前提条件是建立索引，行级锁并不是直接锁记录，而是锁索引。

a先根据code锁住了index然后锁住了primary key，然后根据user_id取锁定对应的index

b同时根据user_id锁住了index然后取锁定primary key，再去锁code的index和primary key

当a根据code锁定住primary key的时候，b锁定了user_id的index

这时候a没办法锁定user_id，b没办法锁定primary key->导致死锁

字符串与整数之间的强制类型转换，行锁升级为表锁

环境准备：事务隔离级别RR

set session autocommit=0;

create table t (
id int(20) primary key AUTO_INCREMENT,
cell varchar(20) unique
)engine=innodb;

事务数据：
Session A：
start transaction;

insert into t(cell)values(44444444444);  [1]
update t set cell=123 where cell=44444444444; [3] 

Session B：
start transaction;

insert into t(cell) values(55555555555); [2] 
update t set cell=456 where cell=55555555555; [4]

[1][2][3][4]为执行时序

现象：

insert into t(cell)values(44444444444);  [1]
事务A插入数据，最先执行

结果：插入成功

insert into t(cell) values(55555555555); [2]
事务B插入数据，第二执行

结果：插入成果

update t set cell=123 where cell=44444444444; [3]
事务A修改[1]中插入的数据，第三执行

结果：阻塞，等待执行结果

update t set cell=456 where cell=55555555555; [4]
事务B修改[2]中插入的数据，最后执行

结果：
（1）事务B死锁，事务B被回滚；
（2）事务A中，[3]语句阻塞结束，执行成功；

结果分析：

两个事务，各自修改自己插入的数据，却产生了死锁，确实诡异。

分析见原文。

结论：

整数强制转换为字符串，导致update因为没有命中索引，导致对每一行都要加锁。并发时，互相等待对方insert时的行锁而导致dead lock。

 

 

 

 

转载于:https://www.cnblogs.com/fanguangdexiaoyuer/p/11252698.html

aixls80424
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
死锁案例 五
谢谢你,慌乱了我的年华
09-17 192
一、前言 死锁其实是一个很有意思也很有挑战的技术问题，大概每个 DBA 和部分开发朋友都会在工作过程中遇见。关于死锁我会持续写一个系列的案例分析，希望能够对想了解死锁的朋友有所帮助。本文是源于生产过程中一个死锁案例。 二、背景知识 官方文档[1]中表述: "REPLACE is done like an INSERT if there is no collision on a unique key. Otherwise, an exclusive next-key lock is placed o
死锁分段信息解读
shunnianlv的博客
10-28 528
服务器发生了死锁的情况时，这部分会显示出来。死锁通常的原因很复杂，但是这一部分只会显示最后两个发生死锁的事务，尽管可能也有其它事务也包含在死锁过程中。不过，尽管信息被删减了，通常也能够通过这些信息找出死锁的原因。 SELECT … FOR SHARE设置一个IS锁，然后 SELECT … FOR UPDATE设置一个IX锁。 表级锁类型兼容性总结在以下矩阵中。 - X IX S IS X 冲突 冲突 冲突 冲突 IX 冲突 兼容的 冲突 兼容的 S 冲突 冲突 兼容的 兼容的 I
mysql 制造一个死锁_MySql一个生产死锁案例分析
weixin_35748716的博客
01-27 802
接到上级一个生产环境MySQL死锁日志信息文件，需要找出原因并解决问题。我将死锁日志部分贴出如下：在mysql中使用命令：SHOW ENGINE INNODB STATUS;总能获取到最近一些问题信息，通过搜索deadlock 关键字即可找到死锁的相关日志信息。2019-09-25 13:28:25 7fc0301ca700InnoDB: transactions deadlock detecte...
mysql遇到的死锁解决面试_面试官问：MySQL发生死锁有哪些原因，怎么避免？
weixin_35834213的博客
01-21 1083
一、锁类型介绍：MySQL有三种锁的级别：页级、表级、行级。表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高,并发度最低。行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低,并发度也最高。页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般算法：next KeyLocks锁，同时锁住记录(数据)，并且锁住记录前面的G...
死锁的成因和对应的解决方案
日常学习记录、分享，愿我们都遇见更好的自己，与诸君共勉
08-02 6056
什么！！！快面试了🤔，这些死锁问题你还不清楚吗😎？
mysql查看死锁与去除死锁示例详解
01-19
新建一个会话执行如下的显示锁示例 LOCK TABLES account_data.account READ; SELECT SLEEP(160); UNLOCK TABLES account_data.account; 另开启一个会话检查锁表情况： mysql> show OPEN TABLES where In_use > 0; ...
线程死锁示例
01-18
本资源为多线程中，多线程共享资源，出现死锁的情况。浅显易懂
Java多线程死锁示例
08-27
主要介绍了Java多线程死锁,结合实例形式分析了Java多线程出现死锁的相关原因与操作注意事项,需要的朋友可以参考下
Oracle外键不加索引引起死锁示例
09-10
主要介绍了Oracle外键不加索引引起死锁的情况及解决,需要的朋友可以参考下
定位MySQL锁和事务问题的两大利器
yinn
03-05 3143
序言MySQL服务器和独立的存储引擎都可以设置锁。一般来说锁分为读锁（或叫共享锁）和写锁（排它锁）。读锁允许并发线程读取加锁的数据，但禁止写数据；相反，写锁禁止其他线程读写操作。 MySQL有4种类型的锁:表锁、行锁、页锁、元数据锁： 表锁：顾名思义会锁住整张表，myisam引擎就实现的是表锁； 行锁：粒度更细，仅锁住正在被线程访问的任意一行或多行，因此同一个表中的其他行仍然可以被其他并发线程访
C例子：死锁
02-01
该程序是我写的博客“一起talk C栗子吧（第一百一十八回：C语言实例--线程死锁二）”的配套程序，共享给大家使用
C例子：死锁too
02-02
该程序是我写的博客“一起talk C栗子吧（（第一百一十九回：C语言实例--线程死锁三）”的配套程序，共享给大家使用
死锁案例一
帅的数说
07-01 919
1、环境说明MySQL5.6.33，隔离级别是RR。表结构及数据：CREATE TABLE `t0` ( `id` int(11) NOT NULL AUTO_INCREMENT, `c` int(11) NOT NULL DEFAULT '0', `d` int(11) NOT NULL DEFAULT '0', PRIMARY KEY (`id`), KEY `c` (`c...
死锁经典案例
liudashuaide的博客
05-28 2201
死锁是这样一种情形：多个线程同时被阻塞，它们中的一个或者全部都在等待某个资源被释放。由于线程被无限期地阻塞，因此程序不可能正常终止。 java 死锁产生的四个必要条件： 1、互斥使用，即当资源被一个线程使用(占有)时，别的线程不能使用 2、不可抢占，资源请求者不能强制从资源占有者手中夺取资源，资源只能由资源占有者主动释放。 3、请求和保持，即当资源请求者在请求其他的资源的同时保持对原有资源的占有。 4、循环等待，即存在一个等待队列：P1占有P2的资源，P2占有P3的资源，P3占有P1的资源。这样就形成了一个
死锁的常见例子及 Python 模拟
wadfdhsajd的博客
09-09 701
常见的例子是在银行账户上：假如要在两个银行账户之间执行交易，你必须确保两个账户都被锁定，不受其他交易的影响，以达到正确的资金转移量。在这里，这个类比并不完全成立--哲学家对应的是锁定账户的交易（分叉）--但同样的技术困难也会出现。其他的例子包括电商秒杀系统，多个用户抢一个商品，不允许一个数据库被多个客户同时修改。死锁也是由一个并发程序需要同时具备的条件来定义的，这样才会发生死锁。这些条件是由计算机科学家Edward G. Coffman, Jr .首先提出的，因此被称为Coffman 条件。
死锁的例子演示
vincent_wen0766的博客
09-19 3540
死锁是什么？有什么危害? 死锁一定发生在并发场景中。我们为了保证线程安全，有时会给程序使用各种能保证并发安全的工具，尤其是锁，但是如果在使用过程中处理不得当，就有可能会导致发生死锁的情况 互不相让 死锁是一种状态，当两个（或多个）线程（或进程）相互持有对方所需要的资源，却又都不主动释放自己手中所持有的资源，导致大家都获取不到自己想要的资源，所有相关的线程（或进程）都无法继续往下执行，在未改变这种状态之前都不能向前推进，我们就把这种状态称为死锁状态，认为它们发生了死锁。通俗的讲，死锁就是两个或多个线程（
死锁及示例
远方的少年
05-20 455
死锁需要满足四个条件 1.互斥 2.持有并等待 3.不可剥夺 4.环形 通常只需要打破其中任意一个就可以解决死锁的问题，通常可以打破第四条，例如资源有序分配的规则。 下面举一个mysql官方文档的死锁例子。 有两个客户端ClientA和ClientB 1.ClientA执行以下sql(持有s锁) START TRANSACTION; SE...
【MYSQL死锁问题】Deadlock found when trying to get lock;
weixin_33736832的博客
12-06 605
2019独角兽企业重金招聘Python工程师标准>>> ...
简单的死锁的例子
记录者的博客
06-29 4737
今天看到了一下死锁,在这里简单记录一下.死锁 : 当A线程等待B线程持有的锁, 同时B线程也在等待A线程持有的锁时, 发生死锁现象;注 : 多线程通信的时候很容易造成死锁,死锁只能避免,不能解决;下面写一个简单例子:/** * 一个简单的死锁类 * 当DeadLock类的对象flag==1时（td1），先锁定o1,睡眠500毫秒 * 而td1在睡眠的时候另一个flag==0的对象（td2）线...
java死锁示例代码 思想家
最新发布
03-30
Java死锁示例代码： ``` public class DeadlockExample { private static Object lock1 = new Object(); private static Object lock2 = new Object(); public static void main(String[] args) { Thread t1 =...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值