关于一次ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction的解决办法

事情前提：

今天在自己本地调试代码的时候，一条普通的插入语句无法执行成功，将SQL语句手动执行，数据库一直显示处理中，最后好久才报出来ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction，（锁等待超时超过;试着重新启动事务），同样的update语句也执行失败，报了同样的错误。

问题排查与处理：

首先推断是数据库事务提交失败。确定方向我们来一步一步的证实自己的想法，因为mysql数据库默认是autocommit的自动提交，那就先查看一下数据库的设置是否真的是自动提交。

mysql> select @@autocommit;+--------------+| @@autocommit |+--------------+|            1 |+--------------+1 row in set

确定是自动提交，那么就没有问题，为了进一步的确定问题，我们需要先知道MYSQL数据库的information_schema 库中三个关于锁的表（MEMORY引擎）；

innodb_trx ## 当前运行的所有事务
innodb_locks ## 当前出现的锁
innodb_lock_waits ## 锁等待的对应关系

下面我们来具体看一下这三个表的表结构：

desc innodb_locks;

+-------------+---------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------------+---------------------+------+-----+---------+-------+
| lock_id | varchar(81) | NO | | | |#锁ID
| lock_trx_id | varchar(18) | NO | | | |#拥有锁的事务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 | |#被锁的数据
+-------------+---------------------+------+-----+---------+-------+
10 rows in set (0.00 sec)

desc innodb_lock_waits;

+-------------------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------------------+-------------+------+-----+---------+-------+
| requesting_trx_id | varchar(18) | NO | | | |#请求锁的事务ID
| requested_lock_id | varchar(81) | NO | | | |#请求锁的锁ID
| blocking_trx_id | varchar(18) | NO | | | |#当前拥有锁的事务ID
| blocking_lock_id | varchar(81) | NO | | | |#当前拥有锁的锁ID
+-------------------+-------------+------+-----+---------+-------+
4 rows in set (0.00 sec)

desc innodb_lock_waits;

+----------------------------+---------------------+------+-----+---------------------+-------+
| Field | Type | Null | Key | Default | Extra |
+----------------------------+---------------------+------+-----+---------------------+-------+
| trx_id | varchar(18) | NO | | | |#事务ID
| trx_state | varchar(13) | NO | | | |#事务状态：
| trx_started | datetime | NO | | 0000-00-00 00:00:00 | |#事务开始时间；
| trx_requested_lock_id | varchar(81) | YES | | NULL | |#innodb_locks.lock_id
| trx_wait_started | datetime | YES | | NULL | |#事务开始等待的时间
| trx_weight | bigint(21) unsigned | NO | | 0 | |#
| trx_mysql_thread_id | bigint(21) unsigned | NO | | 0 | |#事务线程ID
| trx_query | varchar(1024) | YES | | NULL | |#具体SQL语句
| trx_operation_state | varchar(64) | YES | | NULL | |#事务当前操作状态
| trx_tables_in_use | bigint(21) unsigned | NO | | 0 | |#事务中有多少个表被使用
| trx_tables_locked | bigint(21) unsigned | NO | | 0 | |#事务拥有多少个锁
| trx_lock_structs | bigint(21) unsigned | NO | | 0 | |#
| trx_lock_memory_bytes | bigint(21) unsigned | NO | | 0 | |#事务锁住的内存大小（B）
| trx_rows_locked | bigint(21) unsigned | NO | | 0 | |#事务锁住的行数
| trx_rows_modified | bigint(21) unsigned | NO | | 0 | |#事务更改的行数
| trx_concurrency_tickets | bigint(21) unsigned | NO | | 0 | |#事务并发票数
| trx_isolation_level | varchar(16) | NO | | | |#事务隔离级别
| 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 | |#
+----------------------------+---------------------+------+-----+---------------------+-------+
22 rows in set (0.01 sec)

以上这三张表我们只做了解，在遇到问题我们能够知道字段代表着什么含义，接下来，继续来看下数据库的隔离级别

mysql>  select @@tx_isolation;+-----------------+| @@tx_isolation  |+-----------------+| REPEATABLE-READ |+-----------------+1 row in setmysql> 

是可重复读取的，没有问题

再来，我们看下当前库的线程情况

select * from information_schema.innodb_trx （由于是公司的测试库，这里我就打点码哈）

没有看到正在执行的慢SQL记录线程，再去查看innodb的事务表INNODB_TRX，看下里面是否有正在锁定的事务线程，看看ID是否在show full processlist里面的sleep线程中，如果是，就证明这个sleep的线程事务一直没有commit或者rollback而是卡住了，我们需要手动kill掉。

select * from information_schema.innodb_trx 

多查了几遍，发现这个线程id3741149的线程一直存在，手动kill掉此线程

mysql> kill 3741149;Query OK, 0 rows affected (0.00 sec) mysql>

写在最后：

现在在执行insert和update语句，ok，没有问题了，表锁死的问题解决了，但具体由什么原因引起的，我也没有查出来，因为公司的测试库用的人很多，而且有问题的那条线程没有给出是什么语句或者其他信息，无从查起，好在问题解决了，如果日后发现问题原因，我还会贴出来供大家参考的。