轉(zhuǎn)自：http://blog.csdn.net/mchdba/article/details/38313881

之前也遇到一次，今天又遇到了這個問題，所以這次必須解決，網(wǎng)上找到這篇文章幫了大忙，方便以后復(fù)習。這篇文章的解決辦法對于我的情況是有效的。

我的具體情況是：使用RobotFramework測試時，本來可以通過的一個case報錯了，報錯為：InternalError: (1205, u'Lock wait timeout exceeded; try restarting transaction。網(wǎng)上找了很多也沒解決問題，還是這篇文章簡單有效。
2016-10-12更新：找到問題所在了，就是線上開發(fā)環(huán)境和開本地環(huán)境同時跑AT，結(jié)果因為爭搶數(shù)據(jù)庫資源導(dǎo)致數(shù)據(jù)庫死鎖。解決方法其實可以簡化為兩步：1是查出鎖死的數(shù)據(jù)庫線程SELECT trx_mysql_thread_id FROM information_schema.INNODB_TRX;；2是將查出的線程殺死 kill 。

前言：朋友咨詢我說執(zhí)行簡單的update語句失效，癥狀如下：
mysql> update order_info set province_id=15 ,city_id= 1667 where order_from=10 and order_out_sn='1407261241xxxx';
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
mysql>

QQ遠程過去，開始check

1，查看數(shù)據(jù)庫的隔離級別：

mysql> select @@tx_isolation;
+-----------------+
| @@tx_isolation |
+-----------------+
| REPEATABLE-READ |
+-----------------+
1 row in set (0.00 sec)

mysql>

2，去查看先當前庫的線程情況：

mysql> show processlist;
+----------+-----------------+-------------------+-----------------+-------------+---------+-------------------------+-----------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----------+-----------------+-------------------+-----------------+-------------+---------+-------------------------+-----------------------+
| 1 | event_scheduler | localhost | NULL | Daemon | 9635385 | Waiting on empty queue | NULL |
| 9930577 | business_web | 192.168.1.21:45503 | business_db | Sleep | 153 | | NULL |
| 9945825 | business_web | 192.168.1.25:49518 | business_db | Sleep | 43 | | NULL |
| 9946322 | business_web | 192.168.1.23:44721 | business_db | Sleep | 153 | | NULL |
| 9960167 | business_web | 192.168.3.28:2409 | business_db | Sleep | 93 | | NULL |
| 9964484 | business_web | 192.168.1.21:24280 | business_db | Sleep | 7 | | NULL |
| 9972499 | business_web | 192.168.3.28:35752 | business_db | Sleep | 13 | | NULL |
| 10000117 | business_web | 192.168.3.28:9149 | business_db | Sleep | 6 | | NULL |
| 10002523 | business_web | 192.168.3.29:42872 | business_db | Sleep | 6 | | NULL |
| 10007545 | business_web | 192.168.1.21:51379 | business_db | Sleep | 155 | | NULL |
......
+----------+-----------------+-------------------+-----------------+-------------+---------+-------------------------+-----------------------+

沒有看到正在執(zhí)行的慢SQL記錄線程，再去查看innodb的事務(wù)表INNODB_TRX，看下里面是否有正在鎖定的事務(wù)線程，看看ID是否在show full processlist里面的sleep線程中，如果是，就證明這個sleep的線程事務(wù)一直沒有commit或者rollback而是卡住了，我們需要手動kill掉。

mysql> SELECT * FROM information_schema.INNODB_TRX;
*************************** 1. row ***************************
trx_id: 20866
trx_state: LOCK WAIT
trx_started: 2014-07-31 10:42:35
trx_requested_lock_id: 20866:617:3:3
trx_wait_started: 2014-07-30 10:42:35
trx_weight: 2
trx_mysql_thread_id: 9930577
trx_query: delete from dltask where id=1
trx_operation_state: starting index read
trx_tables_in_use: 1
trx_tables_locked: 1
trx_lock_structs: 2
trx_lock_memory_bytes: 376
trx_rows_locked: 1
trx_rows_modified: 0
trx_concurrency_tickets: 0
trx_isolation_level: READ COMMITTED
trx_unique_checks: 1
trx_foreign_key_checks: 1
trx_last_foreign_key_error: NULL
trx_adaptive_hash_latched: 0
trx_adaptive_hash_timeout: 10000
trx_is_read_only: 0
trx_autocommit_non_locking: 0

3，看到有這條9930577的sql，kill掉，執(zhí)行kill 9930577;

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

mysql>

然后再去查詢INNODB_TRX表，就沒有阻塞的事務(wù)sleep線程存在了，如下所示：
mysql> SELECT * FROM INNODB_TRX;
Empty set (0.00 sec)

ERROR:
No query specified

mysql>
再去執(zhí)行update語句，就能正常執(zhí)行了，如下所示：
mysql> update order_info set province_id=15 ,city_id= 1667 where order_from=10 and order_out_sn='1407261241xxxx';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0

mysql>

4，總結(jié)分析

表數(shù)據(jù)量也不大，按照普通的情況來說，簡單的update應(yīng)該不會造成阻塞的，mysql都是autocommit，不會出現(xiàn)update卡住的情況，去查看下autocommit的值。
mysql> select @@autocommit;
+--------------+
| @@autocommit |
+--------------+
| 0 |
+--------------+
1 row in set (0.00 sec)

mysql>

看到亮閃閃的0，這個設(shè)置導(dǎo)致原來的update語句如果沒有commit的話，你再重新執(zhí)行update語句，就會等待鎖定，當?shù)却龝r間過長的時候，就會報ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction的錯誤。
所以趕緊commit剛才執(zhí)行的update語句，之后 set global autocommit=1;