|
副问题[/!--empirenews.page--]
配景
提及Mysql死锁，之前写过一次有关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、哀求与保持前提。
3、不剥夺前提。
4、轮回守候。
从日记上来看事宜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);
- }
- }
（编辑：湖南网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
