錯(cuò)誤示例：Lock wait timeout exceeded; try restarting transaction(SQL: update table set field= field + 1 where id = 111)......
出現(xiàn)此問題的原因：當(dāng)一個(gè)SQL執(zhí)行完了，但未COMMIT，后面的SQL想要執(zhí)行就是被鎖，超時(shí)結(jié)束；
解決方案：
找到原始的鎖ID，然后KILL掉一直持有的那個(gè)線程就可以了；
but光從數(shù)據(jù)庫(kù)無法著手找出源頭是哪個(gè)SQL鎖住了；
有時(shí)候看看show engine innodb status , 并結(jié)合 show full processlist;能暫時(shí)解決問題；但一直不能精確定位；
在5.5中，information_schema庫(kù)中增加了三個(gè)關(guān)于鎖的表（MEMORY引擎）；
innodb_trx ## 當(dāng)前運(yùn)行的所有事務(wù)
innodb_locks ## 當(dāng)前出現(xiàn)的鎖
innodb_lock_waits ## 鎖等待的對(duì)應(yīng)關(guān)系
下面來看一下這三個(gè)關(guān)于鎖的表字段信息：
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ù)開始時(shí)間；
| trx_requested_lock_id | varchar(81) | YES | | NULL ||#innodb_locks.lock_id
| trx_wait_started | datetime | YES | | NULL ||#事務(wù)開始等待的時(shí)間
| 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ù)中有多少個(gè)表被使用
| trx_tables_locked | bigint(21) unsigned | NO | | 0 ||#事務(wù)擁有多少個(gè)鎖
| trx_lock_structs | bigint(21) unsigned | NO | | 0 | |#
| trx_lock_memory_bytes | bigint(21) unsigned | NO | | 0 ||#事務(wù)鎖住的內(nèi)存大?。˙）
| 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ù)隔離級(jí)別
| trx_unique_checks | int(1) | NO | | 0 | |#是否唯一性檢查
| trx_foreign_key_checks | int(1) | NO | | 0 | |#是否外鍵檢查
| trx_last_foreign_key_error | varchar(256) | YES | | NULL ||#最后的外鍵錯(cuò)誤
| trx_adaptive_hash_latched | int(1) | NO | | 0 | |#
| trx_adaptive_hash_timeout | bigint(21) unsigned | NO | | 0 ||#
+----------------------------+---------------------+------+-----+---------------------+-------+
22 rows in set (0.01 sec)
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 ||#被鎖的表空間號(hào)
| lock_page | bigint(21) unsigned | YES | | NULL ||#被鎖的頁號(hào)
| lock_rec | bigint(21) unsigned | YES | | NULL ||#被鎖的記錄號(hào)
| lock_data | varchar(8192) | YES | | NULL | |#被鎖的數(shù)據(jù)
+-------------+---------------------+------+-----+---------+-------+
10 rows in set (0.00 sec)
innodb_lock_waits
+-------------------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------------------+-------------+------+-----+---------+-------+
| requesting_trx_id | varchar(18) | NO | | | |#請(qǐng)求鎖的事務(wù)ID
| requested_lock_id | varchar(81) | NO | | | |#請(qǐng)求鎖的鎖ID
| blocking_trx_id | varchar(18) | NO | | | |#當(dāng)前擁有鎖的事務(wù)ID
| blocking_lock_id | varchar(81) | NO | | | |#當(dāng)前擁有鎖的鎖ID
+-------------------+-------------+------+-----+---------+-------+
4 rows in set (0.00 sec)
根據(jù) select * from information_schema.innodb_trx 你可以獲取被鎖的事務(wù)進(jìn)程信息
有圖可看出，線程 7261707 忘掉 COMMIT 了，然后我們執(zhí)行 kill 7261707 將其殺死即可。
