Mysql死鎖排查實(shí)例分析

這篇文章主要介紹“MySQL死鎖排查實(shí)例分析”的相關(guān)知識(shí)，小編通過實(shí)際案例向大家展示操作過程，操作方法簡(jiǎn)單快捷，實(shí)用性強(qiáng)，希望這篇“Mysql死鎖排查實(shí)例分析”文章能幫助大家解決問題。

創(chuàng)新互聯(lián)建站服務(wù)項(xiàng)目包括泰州網(wǎng)站建設(shè)、泰州網(wǎng)站制作、泰州網(wǎng)頁(yè)制作以及泰州網(wǎng)絡(luò)營(yíng)銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢(shì)、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，泰州網(wǎng)站推廣取得了明顯的社會(huì)效益與經(jīng)濟(jì)效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到泰州省份的部分城市，未來相信會(huì)繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！

問題初現(xiàn)

在某天下午，突然系統(tǒng)報(bào)警，拋出個(gè)異常：

仔細(xì)一看好像是事務(wù)回滾異常，寫著的是因?yàn)樗梨i回滾，原來是個(gè)死鎖問題，由于我對(duì)Mysql鎖還是有一定 了解的，于是開始主動(dòng)排查這個(gè)問題。

首先在數(shù)據(jù)庫(kù)中查找Innodb Status，在Innodb Status中會(huì)記錄上一次死鎖的信息，輸入下面命令：

SHOW ENGINE INNODB STATUS

死鎖信息如下，sql信息進(jìn)行了簡(jiǎn)單處理：

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

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）

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

給大家簡(jiǎn)單的分析解釋一下這段死鎖日志，事務(wù)1執(zhí)行Update語(yǔ)句的時(shí)候需要獲取uidx_tenant這個(gè)索引再where條件上的X鎖（行鎖），事務(wù)2執(zhí)行同樣的Update語(yǔ)句，也在uidx_tenant上面想要獲取X鎖（行鎖），然后就出現(xiàn)了死鎖，回滾了事務(wù)1。當(dāng)時(shí)我就很懵逼，回想了一下死鎖產(chǎn)生的必要條件：

互斥。

請(qǐng)求與保持條件。

不剝奪條件。

循環(huán)等待。 從日志上來看事務(wù)1和事務(wù)2都是取爭(zhēng)奪同一行的行鎖，和以往的互相循環(huán)爭(zhēng)奪鎖有點(diǎn)不同，怎么看都無法滿足循環(huán)等待條件。經(jīng)過同事提醒，既然從死鎖日志中不能進(jìn)行排查，那么就只能從業(yè)務(wù)代碼和業(yè)務(wù)日志從排查。這段代碼的邏輯如下：

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）;

}

}

這段代碼的意思是保存一個(gè)配置文件，如果發(fā)生了唯一索引沖突那么就會(huì)進(jìn)行更新，當(dāng)然這里可能寫得不是很規(guī)范，其實(shí)可以用

insert into …

on duplicate key update

也可以達(dá)到同樣的效果，但是就算用這個(gè)其實(shí)也會(huì)發(fā)生死鎖?？戳舜a之后同事又給我發(fā)了當(dāng)時(shí)業(yè)務(wù)日志，

可以看見這里有三條同時(shí)發(fā)生的日志，說明都發(fā)生了唯一索引沖突進(jìn)入了更新的語(yǔ)句，然后發(fā)生的死鎖。到這里答案終于稍微有點(diǎn)眉目了。

這個(gè)時(shí)候再看我們的表結(jié)構(gòu)如下（做了簡(jiǎn)化處理）：

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

到了這里感覺插入的時(shí)候?qū)ξㄒ凰饕渔i有關(guān)系，接下來我們進(jìn)行下一步的深入剖析。

深入剖析

上面我們說有三個(gè)事務(wù)進(jìn)入update語(yǔ)句，為了簡(jiǎn)化說明這里我們只需要兩個(gè)事務(wù)同時(shí)進(jìn)入update語(yǔ)句即可，下面的表格展示了我們整個(gè)的發(fā)生過程：

小提示：S鎖是共享鎖，X鎖是互斥鎖。一般來說X鎖和S，X鎖都互斥，S鎖和S鎖不互斥。

我們從上面的流程中看見發(fā)生這個(gè)死鎖的關(guān)鍵需要獲取S鎖，為什么我們?cè)俨迦氲臅r(shí)候需要獲取S鎖呢？因?yàn)槲覀冃枰獧z測(cè)唯一索引？在RR隔離級(jí)別下如果要讀取那么就是當(dāng)前讀，那么其實(shí)就需要加上S鎖。這里發(fā)現(xiàn)唯一鍵已經(jīng)存在，這個(gè)時(shí)候執(zhí)行update就會(huì)被兩個(gè)事務(wù)的S鎖互相阻塞，從而形成上面的循環(huán)等待條件。

小提示： 在MVCC中，當(dāng)前讀和快照讀的區(qū)別：當(dāng)前讀每次需要加鎖（可以使共享鎖或者互斥鎖）獲取到最新的數(shù)據(jù)，而快照讀是讀取的是這個(gè)事務(wù)開始的時(shí)候那個(gè)快照，這個(gè)是通過undo log去進(jìn)行實(shí)現(xiàn)的。

這個(gè)就是整個(gè)死鎖的原因，能出現(xiàn)這種死鎖的還有一個(gè)情況，就是同一時(shí)間來三個(gè)插入操作，其中先插入的那個(gè)事務(wù)如果最后回滾了，其余兩個(gè)事務(wù)也會(huì)出現(xiàn)這種死鎖。

解決方案

這里的核心問題是需要把S鎖給干掉，這里有三個(gè)可供參考的解決方案：

將RR隔離級(jí)別，降低成RC隔離級(jí)別。這里RC隔離級(jí)別會(huì)用快照讀，從而不會(huì)加S鎖。

再插入的時(shí)候使用select * for update,加X鎖，從而不會(huì)加S鎖。

可以提前加上分布式鎖，可以利用redis,或者ZK等等，分布式鎖可以參考我的這篇文章。聊聊分布式鎖

第一種方法不太現(xiàn)實(shí)，畢竟隔離級(jí)別不能輕易的修改。第三種方法又比較麻煩。所以第二種方法是我們最后確定的。

關(guān)于“Mysql死鎖排查實(shí)例分析”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)，可以關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，小編每天都會(huì)為大家更新不同的知識(shí)點(diǎn)。

當(dāng)前名稱：Mysql死鎖排查實(shí)例分析
當(dāng)前網(wǎng)址：http://www.muchs.cn/article22/gjgjcc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供電子商務(wù)、虛擬主機(jī)、網(wǎng)站營(yíng)銷、網(wǎng)站改版、商城網(wǎng)站、App設(shè)計(jì)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)