ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
原文連結：http://www.linuxidc.com/Linux/2014-08/105078.htm
前言：朋友諮詢我說執行簡單的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，檢視資料庫的隔離級別：
mysql> select @@tx_isolation;
+-----------------+
| @@tx_isolation |
+-----------------+
| REPEATABLE-READ |
+-----------------+
1 row in set (0.00 sec)
mysql>
2，去檢視先當前庫的執行緒情況：
mysql> show full 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 |
......
+----------+-----------------+-------------------+-----------------+-------------+---------+-------------------------+-----------------------+
沒有看到正在執行的慢SQL記錄執行緒，再去檢視innodb的事務表INNODB_TRX，看下里面是否有正在鎖定的事務執行緒，看看ID是否在show full processlist裡面的sleep執行緒中，如果是，就證明這個sleep的執行緒事務一直沒有commit或者rollback而是卡住了，我們需要手動kill掉。
mysql> SELECT * FROM information_schema.INNODB_TRX\G;
*************************** 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掉，執行kill 9930577;
mysql> kill 9930577;
Query OK, 0 rows affected (0.00 sec)
mysql>
然後再去查詢INNODB_TRX表，就沒有阻塞的事務sleep執行緒存在了，如下所示：
mysql> SELECT * FROM INNODB_TRX\G;
Empty set (0.00 sec)
ERROR:
No query specified
mysql>
再去執行update語句，就能正常執行了，如下所示：
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，總結分析
表資料量也不大，按照普通的情況來說，簡單的update應該不會造成阻塞的，mysql都是autocommit，不會出現update卡住的情況，去檢視下autocommit的值。
mysql> select @@autocommit;
+--------------+
| @@autocommit |
+--------------+
| 0 |
+--------------+
1 row in set (0.00 sec)
mysql>
看到亮閃閃的0，這個設定導致原來的update語句如果沒有commit的話，你再重新執行update語句，就會等待鎖定，當等待時間過長的時候，就會報ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction的錯誤。
所以趕緊commit剛才執行的update語句，之後 set global autocommit=1;
以下原文連結：http://www.cnblogs.com/simpledev/p/5426705.html
前面已經瞭解了InnoDB關於在出現鎖等待的時候，會根據引數innodb_lock_wait_timeout的配置，判斷是否需要進行timeout的操作，本文件介紹在出現鎖等待時候的檢視及分析處理；
在InnoDB Plugin之前，一般通過show full processlist（很難發現被鎖的行記錄問題所在）和show engine innodb status命令檢視當前的資料庫請求，然後再判斷當前事務中鎖的情況。隨著mysql的發展，已經提供更加便捷的方法來監控資料庫中的鎖等待現象了。
在information_schema下面有三張表:INNODB_TRX、INNODB_LOCKS、INNODB_LOCK_WAITS（解決問題方法），通過這三張表，可以更簡單地監控當前的事務並分析可能存在的問題。
比較常用的列：
trx_id:InnoDB儲存引擎內部唯一的事物ID
trx_status:當前事務的狀態
trx_status:事務的開始時間
trx_requested_lock_id：等待事務的鎖ID
trx_wait_started：事務等待的開始時間
trx_weight：事務的權重，反應一個事務修改和鎖定的行數，當發現死鎖需要回滾時，權重越小的值被回滾
trx_mysql_thread_id：MySQL中的程序ID，與show processlist中的ID值相對應
trx_query：事務執行的SQL語句
kill 程序ID; 工作中遇到了一條車輛記錄，select * from car for update 或者是修改某個欄位的值，就報錯：Lock wait timeout exceeded; try restarting transaction解決方法，另外從根本上從業務邏輯程式碼優化對資料庫的操作，之前也遇到過此類情況，比如剛剛修改完這條記錄，接著再次修改，也會報此錯誤，從程式碼和業務層面儘量避免開來。