關於MySQL的lock wait timeout exceeded解決方案

關於MySQL出現 lock wait timeout exceeded; try restarting transaction 的解決方案。

1、問題拋出

在作查詢語句時,MySQL 拋出了這樣的異常:mysql

MySQL server error report:Array
(
    [0] => Array
        (
            [message] => MySQL Query Error
        )

    [1] => Array
        (
            [sql] => SELECT * FROM taobao_trade WHERE order_status = 1 and orderID ='2018061812306547' AND is_tran_success=0 for update
        )

    [2] => Array
        (
            [error] => Lock wait timeout exceeded; try restarting transaction
        )

    [3] => Array
        (
            [errno] => 1205
        )

)

Lock wait timeout exceeded; try restarting transaction的異常,錯誤提示的意思,很明顯,是由於這條語句被鎖住了,因此釋放這個鎖。sql

2、解決方案

咱們能夠經過到information_schema 中來進行查找被鎖的語句。數據庫

解釋: information_schema這張數據表保存了MySQL服務器全部數據庫的信息。如數據庫名,數據庫的表,表欄的數據類型與訪問權限等。再簡單點,這臺MySQL服務器上,到底有哪些數據庫、各個數據庫有哪些表,每張表的字段類型是什麼,各個數據庫要什麼權限才能訪問,等等信息都保存在information_schema表裏面。

咱們能夠用下面三張表來查緣由:服務器

  • innodb_trx 當前運行的全部事務
  • innodb_locks 當前出現的鎖
  • innodb_lock_waits 鎖等待的對應關係

若是數據庫中有鎖的話,咱們可使用這條語句來查看:mysql優化

select * from information_schema.innodb_trx

clipboard.png

圖中紅色語句 LOCK WAIT爲佔用系統資源的語句,咱們須要殺掉這個鎖,執行 kill 線程id號。上面這條記錄的id爲199120823069, trx_mysql_thread_id 爲 738178711, 因此咱們執行:kill 738178711殺掉這個MySQL語句的線程便可。 優化

執行以後:spa

kill 738178711

// 查詢線程
// SELECT * from information_schema.processlist WHERE id = 738178711;
// show full processlist;

clipboard.png

其餘的記錄不須要關注,由於其餘的記錄狀態爲「RUNNING」 即正在執行的事務,並無鎖。.net

3、三張表字段說明

innodb_trx

desc information_schema.innodb_trx;

clipboard.png

innodb_locks

desc information_schema.innodb_locks;

clipboard.png

innodb_lock_waits

desc information_schema.innodb_lock_waits

clipboard.png

4、終極方法

若是以上方法殺掉線程,但仍是不能解決,則咱們就能夠查找執行線程用時比較久的用戶,而後直接幹掉。線程

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

kill 740097562

這樣把全部耗時比較久的任務幹掉,就能夠解決這個問題了。3d

小結

關於個人那個問題,我經過這個方法 select * from information_schema.innodb_trx 已經殺掉了線程,但經過表直接修改那個id對應的數據,仍是會彈出Lock wait timeout exceeded; try restarting transaction這樣的異常,在網上找了許多未找出具體的解決方法,後來本身靈光一現,能夠找出那些好事比較久的線程,而後把那些可疑的線程殺掉,沒想到這個問題就解決了,能夠正常對這行數據進行操做了。


相關文章:mysql優化—show processlist命令詳解

相關文章
相關標籤/搜索