1、MySQL出現(xiàn)lock wait timeout exceeded; try restarting transaction

我們可以通過(guò)到information_schema 中來(lái)進(jìn)行查找被鎖的語(yǔ)句。

解釋?zhuān)篿nformation_schema這張數(shù)據(jù)表保存了MySQL服務(wù)器所有數(shù)據(jù)庫(kù)的信息。如數(shù)據(jù)庫(kù)名，數(shù)據(jù)庫(kù)的表，表欄的數(shù)據(jù)類(lèi)型與訪問(wèn)權(quán)限等。再簡(jiǎn)單點(diǎn)，這臺(tái)MySQL服務(wù)器上，到底有哪些數(shù)據(jù)庫(kù)、各個(gè)數(shù)據(jù)庫(kù)有哪些表，每張表的字段類(lèi)型是什么，各個(gè)數(shù)據(jù)庫(kù)要什么權(quán)限才能訪問(wèn)，等等信息都保存在information_schema表里面。

我們可以用下面三張表來(lái)查原因：

• innodb_trx 當(dāng)前運(yùn)行的所有事務(wù)
• innodb_locks 當(dāng)前出現(xiàn)的鎖
• innodb_lock_waits 鎖等待的對(duì)應(yīng)關(guān)系

如果數(shù)據(jù)庫(kù)中有鎖的話，我們可以使用這條語(yǔ)句來(lái)查看：

select * from information_schema.innodb_trx

圖中紅色語(yǔ)句 LOCK WAIT為占用系統(tǒng)資源的語(yǔ)句，我們需要?dú)⒌暨@個(gè)鎖，執(zhí)行 kill 線程id號(hào)。上面這條記錄的id為199120823069, trx_mysql_thread_id 為 738178711, 所以我們執(zhí)行：kill 738178711殺掉這個(gè)MySQL語(yǔ)句的線程即可。

執(zhí)行之后：

kill 738178711
// 查詢(xún)線程
// SELECT * from information_schema.processlist WHERE id = 738178711;
// show full processlist;

其他的記錄不需要關(guān)注，因?yàn)槠渌挠涗洜顟B(tài)為“RUNNING” 即正在執(zhí)行的事務(wù)，并沒(méi)有鎖。

2、三張表字段說(shuō)明

innodb_trx

desc information_schema.innodb_trx;

innodb_locks

desc information_schema.innodb_locks;

innodb_lock_waits

desc information_schema.innodb_lock_waits

3、終極方法

如果以上方法殺掉線程，但還是不能解決，則我們就可以查找執(zhí)行線程用時(shí)比較久的用戶(hù)，然后直接干掉。

SELECT * from information_schema.`PROCESSLIST` WHERE Time > 1000 AND USER = 'wonguser' ORDER BY TIME desc;
kill 740097562

這樣把所有耗時(shí)比較久的任務(wù)干掉，就可以解決這個(gè)問(wèn)題了。

4、總結(jié)一下

關(guān)于我的那個(gè)問(wèn)題，我通過(guò)這個(gè)方法 select * from information_schema.innodb_trx 已經(jīng)殺掉了線程，但通過(guò)表直接修改那個(gè)id對(duì)應(yīng)的數(shù)據(jù)，還是會(huì)彈出Lock wait timeout exceeded; try restarting transaction這樣的異常，在網(wǎng)上找了許多未找出具體的解決方法，后來(lái)自己靈光一現(xiàn)，可以找出那些好事比較久的線程，然后把那些可疑的線程殺掉，沒(méi)想到這個(gè)問(wèn)題就解決了，可以正常對(duì)這行數(shù)據(jù)進(jìn)行操作了。

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。