數據庫出現死鎖問題:報錯爲
Lock wait timeout exceeded; try restarting transaction Query:.................
mysql
原來是本人在寫批量操做時,在進行事務處理操做的時候忘記寫提交Connection對象了,也就是事務的提交commit,致使了這個數據庫死鎖的悲劇!sql
在InnoDB Plugin以前,通常經過show full processlist
(很難發現被鎖的行記錄問題所在)和show engine innodb status
命令查看當前的數據庫請求,而後再判斷當前事務中鎖的狀況。隨着mysql的發展,已經提供更加便捷的方法來監控數據庫中的鎖等待現象了。數據庫
在information_schema下面有三張表:INNODB_TRX、INNODB_LOCKS、INNODB_LOCK_WAITS
(解決問題方法),經過這三張表,能夠更簡單地監控當前的事務並分析可能存在的問題。
比較經常使用的列:rest
trx_id:InnoDB存儲引擎內部惟一的事物ID
trx_status:當前事務的狀態
trx_status:事務的開始時間
trx_requested_lock_id:等待事務的鎖ID
trx_wait_started:事務等待的開始時間
trx_weight:事務的權重,反應一個事務修改和鎖定的行數,當發現死鎖須要回滾時,權重越小的值被回滾
trx_mysql_thread_id
:MySQL中的進程ID,與show processlist中的ID值相對應
trx_query:事務運行的SQL語句code
kill該未提交事務的進程ID,將報錯信息中包含的sql語句對應的進程ID給殺死就解決了,因此說在業務邏輯代碼中對數據庫操做的Dao進行事務控制的時候,必定要記得提交事務,不然就可能出現上面的悲劇!orm
另外,對於剛剛修改過的記錄,再次進行修改,也可能出現數據庫死鎖的問題,因此,從代碼和業務層面也應該避免開來。對象