產(chǎn)生該問題的原因

Mysql的 InnoDB存儲引擎是支持事務(wù)的，事務(wù)開啟后沒有被主動Commit。導(dǎo)致該資源被長期占用，其他事務(wù)在搶占該資源時，因上一個事務(wù)的鎖而導(dǎo)致?lián)屨际?！因此出現(xiàn) Lock wait timeout exceeded ，一個SQL執(zhí)行完了,但未COMMIT,后面的SQL想要執(zhí)行就是被鎖,超時結(jié)束。

解決辦法一，應(yīng)急

1.在mysql中查看當(dāng)前所有的進程列表
show full PROCESSLIST;

image.png

2.查看事務(wù)列表
select * from information_schema.INNODB_TRX;

image.png

3.Kill id
根據(jù)2中查詢結(jié)果中的trx_mysql_thread_id字段值，查找1中對應(yīng)的id，在執(zhí)行kill id即可；

解決辦法二，設(shè)置參數(shù)

設(shè)置MySQL鎖等待超時 innodb_lock_wait_timeout=50 ，autocommit=on

解決辦法三，分析

當(dāng)前有哪些事務(wù)在等待鎖？ 這些鎖需要鎖哪些表，鎖哪些索引，鎖哪些記錄和值 ？
處于等待狀態(tài)的相關(guān)SQL是什么？
在等待哪些事務(wù)完成 ？
擁有當(dāng)前鎖的SQL是什么？

在mysql 5.5中，information_schema 庫中增加了三個關(guān)于鎖的表（MEMORY引擎）；
innodb_trx ## 當(dāng)前運行的所有事務(wù)
innodb_locks ## 當(dāng)前出現(xiàn)的鎖
innodb_lock_waits ## 鎖等待的對應(yīng)關(guān)系

查看是三個表的表結(jié)構(gòu)

innodb_locks

> desc innodb_locks;
+-------------+---------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------------+---------------------+------+-----+---------+-------+
| lock_id | varchar(81) | NO | | | |#鎖ID
| lock_trx_id | varchar(18) | NO | | | |#擁有鎖的事務(wù)ID
| lock_mode | varchar(32) | NO | | | |#鎖模式
| lock_type | varchar(32) | NO | | | |#鎖類型
| lock_table | varchar(1024) | NO | | | |#被鎖的表
| lock_index | varchar(1024) | YES | | NULL | |#被鎖的索引
| lock_space | bigint(21) unsigned | YES | | NULL | |#被鎖的表空間號
| lock_page | bigint(21) unsigned | YES | | NULL | |#被鎖的頁號
| lock_rec | bigint(21) unsigned | YES | | NULL | |#被鎖的記錄號
| lock_data | varchar(8192) | YES | | NULL | |#被鎖的數(shù)據(jù)
+-------------+---------------------+------+-----+---------+-------+

innodb_lock_waits

> desc innodb_lock_waits;
+-------------------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------------------+-------------+------+-----+---------+-------+
| requesting_trx_id | varchar(18) | NO | | | |#請求鎖的事務(wù)ID
| requested_lock_id | varchar(81) | NO | | | |#請求鎖的鎖ID
| blocking_trx_id | varchar(18) | NO | | | |#當(dāng)前擁有鎖的事務(wù)ID
| blocking_lock_id | varchar(81) | NO | | | |#當(dāng)前擁有鎖的鎖ID
+-------------------+-------------+------+-----+---------+-------+

innodb_trx

> desc innodb_trx ;
+----------------------------+---------------------+------+-----+---------------------+-------+
| Field | Type | Null | Key | Default | Extra |
+----------------------------+---------------------+------+-----+---------------------+-------+
| trx_id | varchar(18) | NO | | | |#事務(wù)ID
| trx_state | varchar(13) | NO | | | |#事務(wù)狀態(tài)：
| trx_started | datetime | NO | | 0000-00-00 00:00:00 | |#事務(wù)開始時間；
| trx_requested_lock_id | varchar(81) | YES | | NULL | |#innodb_locks.lock_id
| trx_wait_started | datetime | YES | | NULL | |#事務(wù)開始等待的時間
| trx_weight | bigint(21) unsigned | NO | | 0 | |#
| trx_mysql_thread_id | bigint(21) unsigned | NO | | 0 | |#事務(wù)線程ID
| trx_query | varchar(1024) | YES | | NULL | |#具體SQL語句
| trx_operation_state | varchar(64) | YES | | NULL | |#事務(wù)當(dāng)前操作狀態(tài)
| trx_tables_in_use | bigint(21) unsigned | NO | | 0 | |#事務(wù)中有多少個表被使用
| trx_tables_locked | bigint(21) unsigned | NO | | 0 | |#事務(wù)擁有多少個鎖
| trx_lock_structs | bigint(21) unsigned | NO | | 0 | |#
| trx_lock_memory_bytes | bigint(21) unsigned | NO | | 0 | |#事務(wù)鎖住的內(nèi)存大小（B）
| trx_rows_locked | bigint(21) unsigned | NO | | 0 | |#事務(wù)鎖住的行數(shù)
| trx_rows_modified | bigint(21) unsigned | NO | | 0 | |#事務(wù)更改的行數(shù)
| trx_concurrency_tickets | bigint(21) unsigned | NO | | 0 | |#事務(wù)并發(fā)票數(shù)
| trx_isolation_level | varchar(16) | NO | | | |#事務(wù)隔離級別
| trx_unique_checks | int(1) | NO | | 0 | |#是否唯一性檢查
| trx_foreign_key_checks | int(1) | NO | | 0 | |#是否外鍵檢查
| trx_last_foreign_key_error | varchar(256) | YES | | NULL | |#最后的外鍵錯誤
| trx_adaptive_hash_latched | int(1) | NO | | 0 | |#
| trx_adaptive_hash_timeout | bigint(21) unsigned | NO | | 0 | |#
+----------------------------+---------------------+------+-----+---------------------+-------+