mysql 死鎖 MySql 死鎖時的一種解決辦法

之前也遇到一次，今天又遇到了這個問題，所以這次必須解決，網上找到這篇文章幫了大忙，方便以後複習。這篇文章的解決辦法對於我的情況是有效的。

我的具體情況是：使用robotframework測試時，本來可以通過的乙個case報錯了，報錯為：internalerror: (1205, u'lock wait timeout exceeded; try restarting transaction。網上找了很多也沒解決問題，還是這篇文章簡單有效。

2016-10-12更新：找到問題所在了，就是線上開發環境和開本地環境同時跑at，結果因為爭搶資料庫資源導致資料庫死鎖。解決方法其實可以簡化為兩步：1是查出鎖死的資料庫執行緒select trx_mysql_thread_id from information_schema.innodb_trx;；2是將查出的執行緒殺死 kill 。

前言：朋友諮詢我說執行簡單的update語句失效，症狀如下：

mysql> update order_info set province_id=15 ,city_id= 1667 where order_from=10 and order_out_sn='1407261241***x';

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 processlist;

| 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;

*************************** 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;

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='1407261241***x';

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;

mysql 死鎖 MySql 死鎖時的一種解決辦法

mysql 死鎖語句 MySQL死鎖

mysql事務死鎖 MySQL事務死鎖

mysql 死鎖模擬 mysql死鎖示例

mysql 死鎖 MySql 死鎖時的一種解決辦法

mysql 死鎖語句 MySQL死鎖

mysql事務死鎖 MySQL事務 死鎖

mysql 死鎖模擬 mysql死鎖示例

相關推薦

mysql事務死鎖 MySQL事務死鎖