温馨提示×

温馨提示×

您好,登录后才能下订单哦!

密码登录×
登录注册×
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》

Mysql死锁排查实例分析

发布时间:2022-03-04 13:51:14 来源:亿速云 阅读:101 作者:iii 栏目:web开发

这篇文章主要介绍“Mysql死锁排查实例分析”的相关知识,小编通过实际案例向大家展示操作过程,操作方法简单快捷,实用性强,希望这篇“Mysql死锁排查实例分析”文章能帮助大家解决问题。

  问题初现

  在某天下午,突然系统报警,抛出个异常:

  仔细一看好像是事务回滚异常,写着的是因为死锁回滚,原来是个死锁问题,由于我对Mysql锁还是有一定 了解的,于是开始主动排查这个问题。

  首先在数据库中查找Innodb Status,在Innodb Status中会记录上一次死锁的信息,输入下面命令:

  SHOW ENGINE INNODB STATUS

  死锁信息如下,sql信息进行了简单处理:

  ------------------------

  LATEST DETECTED DEADLOCK

  ------------------------

  2019-02-22 15:10:56 0x7eec2f468700

  *** (1) TRANSACTION:

  TRANSACTION 2660206487, ACTIVE 0 sec starting index read

  mysql tables in use 1, locked 1

  LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s)

  MySQL thread id 31261312, OS thread handle 139554322093824, query id 11624975750 10.23.134.92 erp_crm__6f73 updating

  /*id:3637ba36*/UPDATE tenant_config SET

  open_card_point =  0

  where tenant_id = 123

  *** (1) WAITING FOR THIS LOCK TO BE GRANTED:

  RECORD LOCKS space id 1322 page no 534 n bits 960 index uidx_tenant of table ——erp_crm_member_plan——。——tenant_config—— trx id 2660206487 lock_mode X locks rec but not gap waiting

  *** (2) TRANSACTION:

  TRANSACTION 2660206486, ACTIVE 0 sec starting index read

  mysql tables in use 1, locked 1

  3 lock struct(s), heap size 1136, 2 row lock(s)

  MySQL thread id 31261311, OS thread handle 139552870532864, query id 11624975758 10.23.134.92 erp_crm__6f73 updating

  /*id:3637ba36*/UPDATE tenant_config SET

  open_card_point =  0

  where tenant_id = 123

  *** (2) HOLDS THE LOCK(S):

  RECORD LOCKS space id 1322 page no 534 n bits 960 index uidx_tenant of table ——erp_crm_member_plan——。——tenant_config—— trx id 2660206486 lock mode S

  *** (2) WAITING FOR THIS LOCK TO BE GRANTED:

  RECORD LOCKS space id 1322 page no 534 n bits 960 index uidx_tenant of table ——erp_crm_member_plan——。——tenant_config—— trx id 2660206486 lock_mode X locks rec but not gap waiting

  *** WE ROLL BACK TRANSACTION (1)

  ------------

  给大家简单的分析解释一下这段死锁日志,事务1执行Update语句的时候需要获取uidx_tenant这个索引再where条件上的X锁(行锁),事务2执行同样的Update语句,也在uidx_tenant上面想要获取X锁(行锁),然后就出现了死锁,回滚了事务1。当时我就很懵逼,回想了一下死锁产生的必要条件:

  互斥。

  请求与保持条件。

  不剥夺条件。

  循环等待。 从日志上来看事务1和事务2都是取争夺同一行的行锁,和以往的互相循环争夺锁有点不同,怎么看都无法满足循环等待条件。经过同事提醒,既然从死锁日志中不能进行排查,那么就只能从业务代码和业务日志从排查。这段代码的逻辑如下:

  public int saveTenantConfig(PoiContext poiContext, TenantConfigDO tenantConfig) {

  try {

  return tenantConfigMapper.saveTenantConfig(poiContext.getTenantId(), poiContext.getPoiId(), tenantConfig);

  } catch (DuplicateKeyException e) {

  LOGGER.warn("[saveTenantConfig] 主键冲突,更新该记录。context:{}, config:{}", poiContext, tenantConfig);

  return tenantConfigMapper.updateTenantConfig(poiContext.getTenantId(), tenantConfig);

  }

  }

  这段代码的意思是保存一个配置文件,如果发生了唯一索引冲突那么就会进行更新,当然这里可能写得不是很规范,其实可以用

  insert into …

  on duplicate key update

  也可以达到同样的效果,但是就算用这个其实也会发生死锁。看了代码之后同事又给我发了当时业务日志,

  可以看见这里有三条同时发生的日志,说明都发生了唯一索引冲突进入了更新的语句,然后发生的死锁。到这里答案终于稍微有点眉目了。

  这个时候再看我们的表结构如下(做了简化处理):

  CREATE TABLE ——tenant_config—— (

  ——id—— bigint(21) NOT NULL AUTO_INCREMENT,

  ——tenant_id—— int(11) NOT NULL,

  ——open_card_point—— int(11) DEFAULT NULL,

  PRIMARY KEY (——id——),

  UNIQUE KEY ——uidx_tenant—— (——tenant_id——)

  ) ENGINE=InnoDB  DEFAULT CHARSET=utf8mb4 ROW_FORMAT=COMPACT

  我们的tenant_id是用来做唯一索引,我们的插入和更新的where条件都是基于唯一索引来操作的。

  UPDATE tenant_config SET

  open_card_point =  0

  where tenant_id = 123

  到了这里感觉插入的时候对唯一索引加锁有关系,接下来我们进行下一步的深入剖析。

  深入剖析

  上面我们说有三个事务进入update语句,为了简化说明这里我们只需要两个事务同时进入update语句即可,下面的表格展示了我们整个的发生过程:

  小提示:S锁是共享锁,X锁是互斥锁。一般来说X锁和S,X锁都互斥,S锁和S锁不互斥。

  我们从上面的流程中看见发生这个死锁的关键需要获取S锁,为什么我们再插入的时候需要获取S锁呢?因为我们需要检测唯一索引?在RR隔离级别下如果要读取那么就是当前读,那么其实就需要加上S锁。这里发现唯一键已经存在,这个时候执行update就会被两个事务的S锁互相阻塞,从而形成上面的循环等待条件。

  小提示: 在MVCC中,当前读和快照读的区别:当前读每次需要加锁(可以使共享锁或者互斥锁)获取到最新的数据,而快照读是读取的是这个事务开始的时候那个快照,这个是通过undo log去进行实现的。

  这个就是整个死锁的原因,能出现这种死锁的还有一个情况,就是同一时间来三个插入操作,其中先插入的那个事务如果最后回滚了,其余两个事务也会出现这种死锁。

  解决方案

  这里的核心问题是需要把S锁给干掉,这里有三个可供参考的解决方案:

  将RR隔离级别,降低成RC隔离级别。这里RC隔离级别会用快照读,从而不会加S锁。

  再插入的时候使用select * for update,加X锁,从而不会加S锁。

  可以提前加上分布式锁,可以利用Redis,或者ZK等等,分布式锁可以参考我的这篇文章。聊聊分布式锁

  第一种方法不太现实,毕竟隔离级别不能轻易的修改。第三种方法又比较麻烦。所以第二种方法是我们最后确定的。

关于“Mysql死锁排查实例分析”的内容就介绍到这里了,感谢大家的阅读。如果想了解更多行业相关的知识,可以关注亿速云行业资讯频道,小编每天都会为大家更新不同的知识点。

向AI问一下细节

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

AI