说起Mysql死锁,之前写过一次有关Mysql加锁的基本介绍,对于一些基本的Mysql锁或者死锁都有一个简单的认识,可以看下这篇文章为什么开发人员需要了解数据库锁。有了上面的经验之后,本以为对于死锁都能手到擒来,没想到再一个阳光明媚的下午报出了一个死锁,但是这一次却没想象的那么简单。
在某天下午,突然系统报警,抛出个异常:
仔细一看好像是事务回滚异常,写着的是因为死锁回滚,原来是个死锁问题,由于我对Mysql锁还是有一定了解的,于是开始主动排查这个问题。
首先在数据库中查找Innodb的地位,在Innodb状态中会记录上一次死锁的信息,输入下面命令:
显示引擎INNODB状态
死锁信息如下,sql信息进行了简单处理:
------------------------ 最新检测到死锁 ------------------------ 2019-02-22 15:10:56 0 x7eec2f468700 * * *(1)事务: 0秒开始索引读取事务2660206487,活跃 在使用mysql表1,锁定1 锁等待2锁结构(s),堆大小1136,1行锁(s) MySQL线程id 31261312, OS线程处理139554322093824,查询id 11624975750 10.23.134.92 erp_crm__6f73更新/* id: 3637 ba36 */更新tenant_config集 open_card_point=0 在tenant_id=123 * * *(1)等待这个锁被授予: 记录锁空间id 1322页534 n比特960指数uidx_tenant表“erp_crm_member_plan”。‘tenant_config trx id 2660206487 lock_mode X锁rec但不是差距等 * * *(2)事务: 0秒开始索引读取事务2660206486,活跃 在使用mysql表1,锁定1 3锁结构(s),堆大小1136,2行锁(s) MySQL线程id 31261311, OS线程处理139552870532864,查询id 11624975758 10.23.134.92 erp_crm__6f73更新/* id: 3637 ba36 */更新tenant_config集 open_card_point=0 在tenant_id=123 * * *(2)持有的锁(S): 记录锁空间id 1322页534 n比特960指数uidx_tenant表“erp_crm_member_plan”。tenant_config trx id 2660206486锁定模式年代 * * *(2)等待这个锁被授予: 记录锁空间id 1322页534 n比特960指数uidx_tenant表“erp_crm_member_plan”。‘tenant_config trx id 2660206486 lock_mode X锁rec但不是差距等 * * *我们回滚事务(1) - - - - - - - - - - - -
给大家简单的分析解释一下这段死锁日志,事务1执行更新语句的时候需要获取uidx_tenant这个索引再哪条件上的X锁(行锁),事务2执行同样的更新语句,也在uidx_tenant上面想要获取X锁(行锁),然后就出现了死锁,回滚了事务1。当时我就很懵,逼回想了一下死锁产生的必要条件:
1,互斥。
2,请求与保持条件。
3,不剥夺条件。
4,循环等待。
从日志上来看事务1和事务2都是取争夺同一行的行锁,和以往的互相循环争夺锁有点不同,怎么看都无法满足循环等待条件。经过同事提醒,既然从死锁日志中不能进行排查,那么就只能从业务代码和业务日志从排查。这段代码的逻辑如下:
公共int saveTenantConfig (PoiContext PoiContext, TenantConfigDO tenantConfig) { 尝试{ 返回tenantConfigMapper.saveTenantConfig (poiContext.getTenantId (), poiContext.getPoiId (), tenantConfig); }捕捉(DuplicateKeyException e) { 记录器。警告(“[saveTenantConfig]主键冲突,更新该记录.context:{},配置:{}”,poiContext, tenantConfig); 返回tenantConfigMapper.updateTenantConfig (poiContext.getTenantId (), tenantConfig); } }
这段代码的意思是保存一个配置文件,如果发生了唯一索引冲突那么就会进行更新,当然这里可能写得不是很规范,其实可以用
插入…… 在重复键更新
也可以达到同样的效果,但是就算用这个其实也会发生死锁。看了代码之后同事又给我发了当时业务日志,
可以看见这里有三条同时发生的日志,说明都发生了唯一索引冲突进入了更新的语句,然后发生的死锁。到这里答案终于稍微有点眉目了。
这个时候再看我们的表结构如下(做了简化处理):
创建表“tenant_config”( “id”bigint NOT NULL AUTO_INCREMENT (21), tenant_id int(11)非空, “open_card_point”int(11)默认为空, 主键(“id”), 唯一键“uidx_tenant”(“tenant_id”) )引擎=InnoDB的默认字符集=utf8mb4 ROW_FORMAT=紧凑一次神奇的MySQL死锁排查记录