MySql Lock wait timeout exceeded 解決辦法

1、簡單介紹下MySQL出現鎖的幾種常見的場景

1.執行DML操做沒有commit，再執行刪除操做就會鎖表。
2.在同一事務內前後對同一條數據進行插入和更新操做。
3.表索引設計不當，致使數據庫出現死鎖。
4.長事物，阻塞DDL，繼而阻塞全部同表的後續操做。

可是要區分的是Lock wait timeout exceeded與Dead Lock是不同的：

Lock wait timeout exceeded：後提交的事務等待前面處理的事務釋放鎖，可是在等待的時候超過了mysql的鎖等待時間，就會引起這個異常。
也能夠拿下面的話解釋: Mysql的InnoDB存儲引擎是支持事務的，事務開啓後沒有被主動Commit。致使該資源被長期佔用，其餘事務在搶佔該資源時，因上一個事務的鎖而致使搶佔失敗！所以出現 Lock wait timeout exceeded

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

innodb_lock_wait_timeout: 指的是事務等待獲取資源等待的最長時間，超過這個時間還未分配到資源則會返回應用失敗； 當鎖等待超過設置時間的時候，就會報以下的錯誤；ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction。其參數的時間單位是秒，最小可設置爲1s(通常不會設置得這麼小)，最大可設置1073741824秒，默認安裝時這個值是50s(默認參數設置)。

下面介紹在遇到以下問題現象該如何處理？？

現象1：數據更新或新增後數據常常自動回滾。
現象2：表操做總報 Lock wait timeout exceeded 並長時間無反應

解決方法
應急方法：show full processlist; kill掉出現問題的進程。 ps.有的時候經過processlist是看不出哪裏有鎖等待的，當兩個事務都在commit階段是沒法體如今processlist上
根治方法：select * from innodb_trx;查看有是哪些事務佔據了表資源。
ps.經過這個辦法就須要對innodb有一些瞭解纔好處理
提及來很簡單找到它殺掉它就搞定了，可是實際上並無想象的這麼簡單，當問題出現要分析問題的緣由，經過緣由定位業務代碼可能某些地方實現的有問題，從而來避免從此遇到一樣的問題。

2、關於INNODB_TRX,INNODB_LOCKs,INNODB_LOCK_waits,PROCESSLIST表介紹

下面幾張表是innodb的事務和鎖的信息表，理解這些表就能很好的定位問題。來解決上面提到的鎖的問題。

2.一、information_schema.INNODB_TRX表詳情說明

#當前運行的全部事務

SELECT * FROM information_schema.INNODB_TRX;

下面對information_schema.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 的標識。

2.二、information_schema.innodb_locks 表詳情介紹

#當前出現的鎖

SELECT * FROM information_schema.innodb_locks ;

下面對information_schema.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。

2.三、information_schema.innodb_lock_waits 表詳情介紹

#鎖等待的對應關係

SELECT * FROM information_schema.innodb_lock_waits ;

下面對information_schema.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。

2.四、 INFORMATION_SCHEMA.PROCESSLIST表詳情介紹

#PROCESSLIST表記錄了每一個MySql線程的用戶，地址以及操做的db等其餘信息。

select *  from INFORMATION_SCHEMA.PROCESSLIST;

PROCESSLIST表的每一個字段解釋以下：

id:標識ID。這與在SHOW PROCESSLIST語句的Id列、Performance Schema threads表的PROCESSLIST_ID列中顯示的值類型相同，並由CONNECTION_ID()函數返回
user:發出該語句的mysql用戶。
host：發出該語句的客戶機的主機名(系統用戶除外，沒有主機)。
db：默認數據庫。
command：線程正在執行的命令的類型。
time：線程處於當前狀態的時間(以秒爲單位)。
state：指示線程正在執行的操做、事件或狀態。
info：線程正在執行的語句，若是沒有執行任何語句，則爲NULL。

3、鎖等待的處理步驟

3.1 直接查看 innodb_lock_waits 表

SELECT * FROM innodb_lock_waits;

3.2 innodb_locks 表和 innodb_lock_waits 表結合

SELECT * FROM innodb_locks WHERE lock_trx_id IN (SELECT blocking_trx_id FROM innodb_lock_waits);

3.3 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);

3.4查詢 innodb_trx 表:

SELECT trx_id, trx_requested_lock_id, trx_mysql_thread_id, trx_query FROM innodb_trx WHERE trx_state = 'LOCK WAIT';

3.5 kill ID
trx_mysql_thread_id 即kill掉事務線程 ID
SHOW ENGINE INNODB STATUS ;
SHOW PROCESSLIST ;
從上述方法中獲得了相關信息，咱們能夠獲得發生鎖等待的線程 ID，而後將其 KILL 掉。 KILL 掉髮生鎖等待的線程。

4、事務一直處於RUNNING狀態解決辦法

定位步驟以下：

（1）使用以下語句查看事務，找到狀態爲RUNNING的記錄

SELECT * FROM information_schema.INNODB_TRX;

（2）經過trx_mysql_thread_id去查詢information_schema.processlist表，找到執行事務的客戶端請求的SQL線程

select * from information_schema.PROCESSLIST WHERE ID = 'xxx';

（3）查看到端口和host之後，再到對應的服務器查看相關的應用和日誌

netstat -nlatp | grep 23452
ps -eaf | grep 12059

（4）若是沒法定位，此時咱們須要從performance_schema表尋找特定線程的信息

#查看事件

select * from performance_schema.events_statements_current

（5）根據咱們拿到的線程id去查，能夠獲取到具體的執行sql

select * from performance_schema.events_statements_current
where THREAD_ID in (select THREAD_ID from performance_schema.threads where PROCESSLIST_ID=15844)

到此基本上就能分析出問題所在。

要是還找不到問題那就須要開啓MySQL general_log記錄下sql來排查試試:

1. 開啓MySQL的general log
   general log會記錄下發送給MySQL服務器的全部SQL記錄，由於SQL的量大，默認是不開啓的。若是一個問題反覆出現（常常出現事務不結束），這個時候須要把general log打開，事務沒有提交，同樣會寫到general_log，這樣來定位出現問題的SQL。

MySQL有三個參數用於設置general log：

general_log：用於開啓general log。ON表示開啓，OFF表示關閉。
log_output：日誌輸出的模式。FILE表示輸出到文件，TABLE表示輸出到mysq庫的general_log表，NONE表示不記錄general_log。
general_log_file：日記輸出文件的路徑，這是log_output=FILE時纔會輸出到此文件。
查看general_log有沒有開啓

show variables like '%general%';
默認general_log是OFF的，general_log_file是日誌輸出路徑：

mysql> show variables like '%general%';
+------------------+---------------------+
| Variable_name | Value |
+------------------+---------------------+
| general_log | OFF |
| general_log_file | DESKTOP-Q1D3TT5.log |
+------------------+---------------------+
若是general_log是關閉的，執行下面SQL，開啓之：

set global general_log=1;
或
set global general_log=ON;
查看日誌輸出模式

show variables where Variable_name="log_output";
默認是FILE，以下：

mysql> show variables where Variable_name="log_output";
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_output | FILE |
+---------------+-------+
關閉general log

大多數狀況是臨時開啓general log，須要記得關閉，並把日誌的輸出模式恢復爲FILE。
set global general_log=OFF;
set global log_output='FILE'

參考文檔：
https://mingshan.fun/2019/09/01/transaction-running/
https://ningyu1.github.io/site/post/75-mysql-lock-wait-timeout-exceeded/