關於數據庫發生死鎖的問題

數據庫出現死鎖問題：報錯爲 Lock wait timeout exceeded; try restarting transaction Query:.................

發現的問題所在

原來是本人在寫批量操做時，在進行事務處理操做的時候忘記寫提交Connection對象了，也就是事務的提交commit，致使了這個數據庫死鎖的悲劇！

解決方案：

1. 首先必須瞭解的知識：

在InnoDB Plugin以前，通常經過show full processlist（很難發現被鎖的行記錄問題所在）和show engine innodb status命令查看當前的數據庫請求，而後再判斷當前事務中鎖的狀況。隨着mysql的發展，已經提供更加便捷的方法來監控數據庫中的鎖等待現象了。

在information_schema下面有三張表:INNODB_TRX、INNODB_LOCKS、INNODB_LOCK_WAITS（解決問題方法），經過這三張表，能夠更簡單地監控當前的事務並分析可能存在的問題。
比較經常使用的列：

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語句

2. 解決方法：

kill該未提交事務的進程ID，將報錯信息中包含的sql語句對應的進程ID給殺死就解決了，因此說在業務邏輯代碼中對數據庫操做的Dao進行事務控制的時候，必定要記得提交事務，不然就可能出現上面的悲劇！

另外，對於剛剛修改過的記錄，再次進行修改，也可能出現數據庫死鎖的問題，因此，從代碼和業務層面也應該避免開來。