前面已經了解了InnoDB關於在出現鎖等待的時候，會根據參數innodb_lock_wait_timeout的配置，判斷是否需要進行timeout的操作，本文檔介紹在出現鎖等待時候的查看及分析處理；
在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語句
kill 進程ID; 工作中遇到了一條車輛記錄，select * from car for update 或者是修改某個字段的值，就報錯：Lock wait timeout exceeded; try restarting transaction解決方法，另外從根本上從業務邏輯代碼優化對數據庫的操作，之前也遇到過此類情況，比如剛剛修改完這條記錄，接着再次修改，也會報此錯誤，從代碼和業務層面盡量避免開來。