一、更新超時(shí)

最近在生產(chǎn)上遇到了這樣的一個(gè)問題峦嗤，在執(zhí)行到具體的update語句時(shí)嚎于，出現(xiàn)了SQL state [null]; error code [0]; Statement cancelled due to timeout or client request; nested exception is com.mysql.jdbc.exceptions.MySQLTimeoutException: Statement cancelled due to timeout or client request org.springframework.jdbc.UncategorizedSQLException: PreparedStatementCallback;

我們進(jìn)行分析sql,該sql就是一個(gè)很正常的更新操作作谚，按照primaryKey進(jìn)行更新型型。并且我們?cè)谠搒ql上設(shè)置了jdbcTimeout=10，意思是該sql如果執(zhí)行時(shí)間超過10S犹菇，就會(huì)終止執(zhí)行德迹。所以在后臺(tái)服務(wù)器上抓取到了該超時(shí)日志

分析步驟：導(dǎo)致超時(shí)的原因是什么，該sql在執(zhí)行時(shí)揭芍，因?yàn)閣here條件是走的主鍵索引胳搞，所以其會(huì)直接在該數(shù)據(jù)行加X鎖，也就是說如果別的業(yè)務(wù)場(chǎng)景也在這一時(shí)刻做該主鍵行的數(shù)據(jù)更新称杨，則該線程會(huì)被掛起肌毅。如果在10S之內(nèi)A業(yè)務(wù)沒有執(zhí)行完，則B業(yè)務(wù)會(huì)一直等待姑原。如果B等待超過10S之后悬而，則會(huì)拋出該異常。當(dāng)然A本身按照ID更新操作是會(huì)很快執(zhí)行完畢锭汛，并釋放鎖的笨奠。至于A的更新有沒有超時(shí)，當(dāng)時(shí)也進(jìn)行了業(yè)務(wù)分析店乐，發(fā)現(xiàn)A是正常更新完畢的艰躺。

那還會(huì)是什么原因?qū)е律胂窟M(jìn)一步分析眨八，A的更新操作為何會(huì)執(zhí)行很久，最后分析代碼左电，發(fā)現(xiàn)A的更新操作是裹在了一個(gè)大事物里廉侧，當(dāng)A的update語句執(zhí)行完更新操作之后页响，但是其他業(yè)務(wù)未執(zhí)行完，所以無法進(jìn)行數(shù)據(jù)的提交動(dòng)作段誊，導(dǎo)致A的數(shù)據(jù)行X鎖無法及時(shí)釋放闰蚕，所以B在執(zhí)行時(shí)，就會(huì)一直等待连舍，直到超時(shí)没陡。

怎么解：這種問題只能把A的大事物進(jìn)行拆分，盡可能的拆分成小事物

二索赏、死鎖

先來看下后臺(tái)死鎖日志

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

LATEST DETECTED DEADLOCK

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

190619? 8:27:17

*** (1) TRANSACTION:

TRANSACTION 374ECFC5, ACTIVE 0 sec starting index read

mysql tables in use 1, locked 1

LOCK WAIT 11 lock struct(s), heap size 1248, 5 row lock(s), undo log entries 30

MySQL thread id 1271327, OS thread handle 0x7f684f63c700, query id 2386660519 10.96.200.162 JWMSusr Updating

A更新語句盼玄，按照ID去更新

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

RECORD LOCKS space id 3155 page no 5852 n bits 144 index `PRIMARY` of table `庫存表` trx id 374ECFC5 lock_mode X locks rec but not gap

waiting

*** (2) TRANSACTION:

TRANSACTION 374ECDC8, ACTIVE 1 sec starting index read, thread declared inside InnoDB 500

mysql tables in use 1, locked 1

44 lock struct(s), heap size 6960, 31 row lock(s), undo log entries 237

MySQL thread id 1271277, OS thread handle 0x7f665b700700, query id 2386660596 10.96.200.168 JWMSusr Updating

B更新語句，按照ID去更新潜腻。（這里A和B是同一條SQL）

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

RECORD LOCKS space id 3155 page no 5852 n bits 144 index `PRIMARY` of table `庫存表` trx id 374ECDC8 lock_mode X locks rec but not gap

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

RECORD LOCKS space id 3155 page no 5505 n bits 144 index `PRIMARY` of table `庫存表` trx id 374ECDC8 lock_mode X locks rec but not gap

waiting

*** WE ROLL BACK TRANSACTION (1)

以上是我們從數(shù)據(jù)庫服務(wù)器上拉取到的監(jiān)測(cè)日志埃儿，可以看到，死鎖的是因?yàn)閄鎖融涣，而非GAP鎖童番；首先我們來回顧下死鎖產(chǎn)生的幾種方式：

首先死鎖產(chǎn)生的前提必須條件是：至少在兩個(gè)事物以上；其次分為：1威鹿、不同表相同記錄行的鎖沖突剃斧；2、相同表記錄行的鎖沖突忽你；3悯衬、不同索引鎖沖突；4檀夹、GAP鎖沖突筋粗； 從上面的監(jiān)測(cè)日志，可以得知是相同表記錄行的鎖沖突

相同表記錄行的鎖沖突誘發(fā)的場(chǎng)景如下：

由上圖我們可以看到炸渡，當(dāng)兩個(gè)事物包含了對(duì)方彼此的更新表時(shí)娜亿，并且是互相交叉，這樣就會(huì)在MySql層會(huì)主動(dòng)監(jiān)測(cè)到更新閉環(huán)鏈路蚌堵，而引發(fā)死鎖告警买决。

如何解決：如果我們把事物進(jìn)一步拆小，這樣死鎖可以避免吼畏。但是在實(shí)際應(yīng)用場(chǎng)景中督赤，我們事物管理的維度都是按照業(yè)務(wù)場(chǎng)景來走，并非是一個(gè)事物就只有一個(gè)更新操作泻蚊。所以在實(shí)際的考量當(dāng)中躲舌，應(yīng)當(dāng)把業(yè)務(wù)維度盡可能的縮小

同時(shí)盡可能去用主鍵去更新，使鎖粒度達(dá)到行鎖級(jí)別