工作中處理定時任務分發消息時出現的問題，在查找並解決問題的時候，將相關的問題博客收集整理，在此記錄下，以便之后再遇到相同的問題，方便查閱。
問題場景
問題出現的場景：
- 在消息隊列處理消息時，同一事務內先后對同一條數據進行了插入和更新操作;
- 多台服務器操作同一數據庫；
- 瞬時出現高並發現象；
導致數據更新或新增后數據經常自動回滾；表操作總報 Lock wait timeout exceeded 並長時間無反應
問題剖析
原因分析
MySql Lock wait timeout exceeded 這個問題我相信大家對它並不陌生，但是有很多人對它產生的原因以及處理吃的不是特別透，很多情況都是交給DBA去定位和處理問題，接下來我們就針對這個問題來展開討論：
Mysql造成鎖的情況有很多，下面我們就列舉一些情況：
- 執行DML操作沒有commit，再執行刪除操作就會鎖表。
- 在同一事務內先后對同一條數據進行插入和更新操作。
- 表索引設計不當，導致數據庫出現死鎖。
- 長事務，阻塞DDL，繼而阻塞所有同表的后續操作。
但是要區分的是Lock wait timeout exceeded與Dead Lock是不一樣。
Lock wait timeout exceeded：后提交的事務等待前面處理的事務釋放鎖，但是在等待的時候超過了mysql的鎖等待時間，就會引發這個異常。Dead Lock：兩個事務互相等待對方釋放相同資源的鎖，從而造成的死循環，就會引發這個異常。
還有一個要注意的是innodb_lock_wait_timeout與lock_wait_timeout也是不一樣的。
innodb_lock_wait_timeout：innodb的dml操作的行級鎖的等待時間lock_wait_timeout：數據結構ddl操作的鎖的等待時間
那么如何查看innodb_lock_wait_timeout的具體值：
SHOW VARIABLES LIKE 'innodb_lock_wait_timeout'
如何修改innode lock wait timeout的值，參數修改的范圍有Session和Global，並且支持動態修改，可以有兩種方法修改：
方法一：
通過下面語句修改
set innodb_lock_wait_timeout=100;
set global innodb_lock_wait_timeout=100;
ps. 注意global的修改對當前線程是不生效的，只有建立新的連接才生效。
方法二：
修改參數文件/etc/my.cnf innodb_lock_wait_timeout = 50
ps. innodb_lock_wait_timeout指的是事務等待獲取資源等待的最長時間，超過這個時間還未分配到資源則會返回應用失敗； 當鎖等待超過設置時間的時候，就會報如下的錯誤；ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction。其參數的時間單位是秒，最小可設置為1s(一般不會設置得這么小)，最大可設置1073741824秒，默認安裝時這個值是50s(默認參數設置)。
原因總結
- 在高並發的情況下，Spring事物造成數據庫死鎖，后續操作超時拋出異常。
- Mysql數據庫采用InnoDB模式，默認參數:innodb_lock_wait_timeout設置鎖等待的時間是50s，一旦數據庫鎖超過這個時間就會報錯。
解決方法
- 應急方法：
show full processlist;kill掉出現問題的進程。 ps.有的時候通過processlist是看不出哪里有鎖等待的，當兩個事務都在commit階段是無法體現在processlist上 - 根治方法：
select * from information_schema.innodb_trx;查看有是哪些事務占據了表資源。 ps.通過這個辦法就需要對innodb有一些了解才好處理 - 增加鎖等待時間，即增大下面配置項參數值，單位為秒（s）
innodb_lock_wait_timeout=500 - 優化存儲過程,事務避免過長時間的等待
說起來很簡單找到它殺掉它就搞定了，但是實際上並沒有想象的這么簡單，當問題出現要分析問題的原因，通過原因定位業務代碼可能某些地方實現的有問題，從而來避免今后遇到同樣的問題。
擴展資料
參考信息
- 鎖等待超時。是當前事務在等待其它事務釋放鎖資源造成的。可以找出鎖資源競爭的表和語句，優化SQL，創建索引等。如果還是不行，可以適當減少並發線程數。
- 事務在等待給某個表加鎖時超時，估計是表正被另的進程鎖住一直沒有釋放。
可以用 SHOW INNODB STATUS/G; 看一下鎖的情況。 - 搜索解決之道，在管理節點的[ndbd default]區加：
TransactionDeadLockDetectionTimeOut=10000（設置 為10秒）默認是1200（1.2秒） - InnoDB會自動的檢測死鎖進行回滾，或者終止死鎖的情況。
InnoDB automatically detects transaction deadlocks and rolls back a transaction or transactions to break the deadlock. InnoDB tries to pick small transactions to roll back, where the size of a transaction is determined by the number of rows inserted, updated, or deleted.
如果參數innodb_table_locks=1並且autocommit=0時，InnoDB會留意表的死鎖，和MySQL層面的行級鎖。另外，InnoDB不會檢測MySQL的Lock Tables命令和其他存儲引擎死鎖。你應該設置innodb_lock_wait_timeout來解決這種情況。
innodb_lock_wait_timeout是Innodb放棄行級鎖的超時時間。
Innodb_* 表的解釋
Mysql的InnoDB存儲引擎是支持事務的，事務開啟后沒有被主動Commit。導致該資源被長期占用，其他事務在搶占該資源時，因上一個事務的鎖而導致搶占失敗！因此出現 Lock wait timeout exceeded
下面幾張表是innodb的事務和鎖的信息表，理解這些表就能很好的定位問題。
innodb_trx## 當前運行的所有事務innodb_locks## 當前出現的鎖innodb_lock_waits## 鎖等待的對應關系
下面對 innodb_trx 表的每個字段進行解釋：
trx_id：事務ID。
trx_state：事務狀態，有以下幾種狀態：RUNNING、LOCK WAIT、ROLLING BACK 和 COMMITTING。
trx_started：事務開始時間。
trx_requested_lock_id：事務當前正在等待鎖的標識，可以和 INNODB_LOCKS 表 JOIN 以得到更多詳細信息。
trx_wait_started：事務開始等待的時間。
trx_weight：事務的權重。
trx_mysql_thread_id：事務線程 ID，可以和 PROCESSLIST 表 JOIN。
trx_query：事務正在執行的 SQL 語句。
trx_operation_state：事務當前操作狀態。
trx_tables_in_use：當前事務執行的 SQL 中使用的表的個數。
trx_tables_locked：當前執行 SQL 的行鎖數量。
trx_lock_structs：事務保留的鎖數量。
trx_lock_memory_bytes：事務鎖住的內存大小，單位為 BYTES。
trx_rows_locked：事務鎖住的記錄數。包含標記為 DELETED，並且已經保存到磁盤但對事務不可見的行。
trx_rows_modified：事務更改的行數。
trx_concurrency_tickets：事務並發票數。
trx_isolation_level：當前事務的隔離級別。
trx_unique_checks：是否打開唯一性檢查的標識。
trx_foreign_key_checks：是否打開外鍵檢查的標識。
trx_last_foreign_key_error：最后一次的外鍵錯誤信息。
trx_adaptive_hash_latched：自適應散列索引是否被當前事務鎖住的標識。
trx_adaptive_hash_timeout：是否立刻放棄為自適應散列索引搜索 LATCH 的標識。
下面對 innodb_locks 表的每個字段進行解釋：
lock_id：鎖 ID。
lock_trx_id：擁有鎖的事務 ID。可以和 INNODB_TRX 表 JOIN 得到事務的詳細信息。
lock_mode：鎖的模式。有如下鎖類型：行級鎖包括：S、X、IS、IX，分別代表：共享鎖、排它鎖、意向共享鎖、意向排它鎖。表級鎖包括：S_GAP、X_GAP、IS_GAP、IX_GAP 和 AUTO_INC，分別代表共享間隙鎖、排它間隙鎖、意向共享間隙鎖、意向排它間隙鎖和自動遞增鎖。
lock_type：鎖的類型。RECORD 代表行級鎖，TABLE 代表表級鎖。
lock_table：被鎖定的或者包含鎖定記錄的表的名稱。
lock_index：當 LOCK_TYPE=’RECORD’ 時，表示索引的名稱；否則為 NULL。
lock_space：當 LOCK_TYPE=’RECORD’ 時，表示鎖定行的表空間 ID；否則為 NULL。
lock_page：當 LOCK_TYPE=’RECORD’ 時，表示鎖定行的頁號；否則為 NULL。
lock_rec：當 LOCK_TYPE=’RECORD’ 時，表示一堆頁面中鎖定行的數量，亦即被鎖定的記錄號；否則為 NULL。
lock_data：當 LOCK_TYPE=’RECORD’ 時，表示鎖定行的主鍵；否則為NULL。
下面對 innodb_lock_waits 表的每個字段進行解釋：
requesting_trx_id：請求事務的 ID。
requested_lock_id：事務所等待的鎖定的 ID。可以和 INNODB_LOCKS 表 JOIN。
blocking_trx_id：阻塞事務的 ID。
blocking_lock_id：某一事務的鎖的 ID，該事務阻塞了另一事務的運行。可以和 INNODB_LOCKS 表 JOIN。
鎖等待的處理步驟
- 直接查看 innodb_lock_waits 表
SELECT * FROM innodb_lock_waits;
- innodb_locks 表和 innodb_lock_waits 表結合：
SELECT * FROM innodb_locks WHERE lock_trx_id IN (SELECT blocking_trx_id FROM innodb_lock_waits);
- innodb_locks 表 JOIN innodb_lock_waits 表:
SELECT innodb_locks.* FROM innodb_locks JOIN innodb_lock_waits ON (innodb_locks.lock_trx_id = innodb_lock_waits.blocking_trx_id);
- 查詢 innodb_trx 表:
SELECT trx_id, trx_requested_lock_id, trx_mysql_thread_id, trx_query FROM innodb_trx WHERE trx_state = 'LOCK WAIT';
- trx_mysql_thread_id 即kill掉事務線程 ID
SHOW ENGINE INNODB STATUS ;
SHOW PROCESSLIST ;
從上述方法中得到了相關信息，我們可以得到發生鎖等待的線程 ID，然后將其 KILL 掉。 KILL 掉發生鎖等待的線程。
kill ID;