一、mysql死鎖及超時的原因
當在業(yè)務邏輯中看到這個錯誤，或者mysql中使用update語句更新數(shù)據(jù)報錯： Lock wait timeout exceeded; try restarting transaction。也就是遇到了mysql死鎖，等待資源，事務鎖的問題。
可能原因：意外處理沒有關閉連接，導致連接過多、或是要更新的表的鎖在其它線程手里、系統(tǒng)異常導致事務未提交，再次請求相同記錄等等。
InnoDB關于在出現(xiàn)鎖等待的時候，會根據(jù)參數(shù)innodb_lock_wait_timeout的配置（默認50s），判斷是否需要進行timeout的操作：
二、mysql死鎖排查思路
1、show full processlist 查詢當前數(shù)據(jù)庫全部線程
show full processlist 查詢當前數(shù)據(jù)庫全部線程
show engine innodb status命令查看當前的數(shù)據(jù)庫請求，然后再判斷當前事務中鎖的情況
select * from information_schema.innodb_trx 查詢當前運行的全部事務
注：select * from information_schema.innodb_trx;
MySQL 5.5版本以上才可以用此方法，5.5版本以下會沒有這個表;[Err] 1109 - Unknown table 'innodb_trx' in information_schema
當中trx_mysql_thread_id為事務線程的id，參照show full processlist命令中的線程信息查看
如果數(shù)據(jù)庫中有鎖的話，LOCK WAIT的就是鎖等待的
此時你可以直接使用命令：kill 事務線程id 殺掉它。比如：kill 99999
沒有的話，找到Command 狀態(tài)是query 并且Time 時間很長的id）有時候一定程度上也能解決一定的問題。
再用 show full processlist 查詢當前數(shù)據(jù)庫全部線程，發(fā)現(xiàn)剛才的線程沒了。
但是一般這樣還是很難發(fā)現(xiàn)被鎖的行記錄問題所在
2、information_schema
information_schema這張數(shù)據(jù)表保存了MySQL服務器所有數(shù)據(jù)庫的信息。
我們可以用這三張表innodb_trx、innodb_locks、innodb_lock_waits，使用如下命令，簡單地監(jiān)控當前的事務并分析可能存在的問題：
select * from information_schema.innodb_trx （ 當前運行的所有事務）
select * from information_schema.innodb_locks （當前出現(xiàn)的鎖）
select * from information_schema.innodb_lock_waits （鎖等待的對應關系）
注意：在8.0.13版本中
innodb_locks表由performance_schema.data_locks表所代替，
innodb_lock_waits表則由performance_schema.data_lock_waits表代替。
三張表具體信息：
其中比較常用的一些列：
- trx_id:InnoDB存儲引擎內(nèi)部唯一的事物ID
- trx_status:當前事務的狀態(tài)
- trx_status:事務的開始時間
- trx_requested_lock_id：等待事務的鎖ID
- trx_wait_started：事務等待的開始時間
- trx_weight：事務的權(quán)重，反應一個事務修改和鎖定的行數(shù)，當發(fā)現(xiàn)死鎖需要回滾時，權(quán)重越小的值被回滾
- trx_mysql_thread_id：MySQL中的進程ID，與show processlist中的ID值相對應
- trx_query：事務運行的SQL語句
綜上大體可以清楚的找到等待的事務即沒有獲取鎖的事務，進一步調(diào)整業(yè)務邏輯代碼。
一些建議：
1、可以結(jié)合update語句，調(diào)整索引，讓update能唯一定位到數(shù)據(jù)行，盡量退化到行鎖粒度；
2、相關查詢語句增加索引，減少事物整體耗時；
3、避免長事物、可以降低@Transactional的粒度；
4、減少批處理數(shù)據(jù)量，規(guī)范業(yè)務邏輯流程，考慮異常事務回滾等問題；
