.jpg)
分享一個(gè)MySQL死鎖問題解決的方法
一、環(huán)境
-
centos, mysql 5.6.21-70, jpa
-
問題場景：系統(tǒng)有定時(shí)批量更新數(shù)據(jù)狀態(tài)操作，每次更新上千條記錄，表中總記錄數(shù)約為500W左右。
二、錯(cuò)誤日志
2017-2-25?17:38:41?org.hibernate.util.JDBCExceptionReporter?logExceptions 嚴(yán)重:?Lock?wait?timeout?exceeded;?try?restarting?transaction 2017-2-25?17:39:05?org.hibernate.util.JDBCExceptionReporter?logExceptions 警告:?SQL?Error:?1213,?SQLState:?40001 2017-2-25?17:39:05?org.hibernate.util.JDBCExceptionReporter?logExceptions 嚴(yán)重:?Deadlock?found?when?trying?to?get?lock;?try?restarting?transaction
三、排查
Check?InnoDB?status?for?locks mysql>?SHOW?ENGINE?InnoDB?STATUS; Check?MySQL?open?tables mysql>?SHOW?OPEN?TABLES?WHERE?In_use?>?0; Check?pending?InnoDB?transactions mysql>?SELECT?*?FROM?`information_schema`.`innodb_trx`?ORDER?BY?`trx_started`;? Check?lock?dependency?-?what?blocks?what mysql>?SELECT?*?FROM?`information_schema`.`innodb_locks`;
排查后發(fā)現(xiàn)都是執(zhí)行類似這樣的語句出現(xiàn)問題的：
update?t_task_tel?set?state='iok',?update_date='2017-02-27?11:03:02'?where?tel_id=66042?and?task_id=350199;
四、分析
搜索相關(guān)資料后發(fā)現(xiàn)，原來MySQL InnoDB并不一定都是行級(jí)鎖。
相關(guān)參考資料片段如下：
鎖選擇
1）、如果更新條件沒有走索引，例如執(zhí)行”update?from?t1?set?v2=0?where?v2=5;”?，此時(shí)會(huì)進(jìn)行全表掃描，掃表的時(shí)候，要阻止其他任何的更新操作，所以上升為表鎖。
2）、如果更新條件為索引字段，但是并非唯一索引（包括主鍵索引），例如執(zhí)行“update?from?t1?set?v2=0?where?v1=9;”?
那么此時(shí)更新會(huì)使用Next-Key?Lock。使用Next-Key?Lock的原因：
a）、首先要保證在符合條件的記錄上加上排他鎖，會(huì)鎖定當(dāng)前非唯一索引和對應(yīng)的主鍵索引的值；
b）、還要保證鎖定的區(qū)間不能插入新的數(shù)據(jù)。
3）、如果更新條件為唯一索引，則使用Record?Lock（記錄鎖）。
?
InnoDB根據(jù)唯一索引，找到相應(yīng)記錄，將主鍵索引值和唯一索引值加上記錄鎖。但不使用Gap?Lock（間隙鎖）。
由于InnoDB預(yù)設(shè)是Row-Level?Lock，所以只有「明確」的指定主鍵，MySQL才會(huì)執(zhí)行Row?lock?(只鎖住被選取的資料例)?，否則MySQL將會(huì)執(zhí)行Table?Lock?(將整個(gè)資料表單給鎖住)。
根據(jù)分析結(jié)論，猜測是在更新_task_tel表時(shí)Where條件中tel_id和task_id沒有建立UNIQUE(唯一索引)原因;
五、解決
據(jù)此分析，嘗試通過tel_id和task_id兩個(gè)字段建立UNIQUE(唯一索引)來解決。 (也可以先查詢出來，然后根據(jù)主鍵ID來更新，這樣不會(huì)因表中數(shù)據(jù)量較大影響線上業(yè)務(wù))。
通過此種方式解決后，問題沒有再重現(xiàn)。
如果你的問題和我遇到的類似，可以嘗試據(jù)此解決。
.png)
