天天看點

lock wait timeout exceeded; try restarting transactio解決方案

問題原因:

       今天線上環境,突然出現一個問題,追蹤原因是資料庫中的一條語句報錯,錯誤内容:

lock wait timeout exceeded; try restarting transactio

       執行update table set status = 1 where id = 10002;是可以的。

       而執行update table set status = 1 where id = 10001;這條語句執行失敗。

       錯誤提示的意思,很明顯,是因為這條語句被鎖住了。是以釋放這個鎖。

解決方案:

       新建立的資料庫,是這樣子的:

       新建立的資料庫結構

       現在我們要查test庫中使用情況,我們可以到information_schema中查詢

       解釋:information_schema這張資料表儲存了MySQL伺服器所有資料庫的資訊。如資料庫名,資料庫的表,表欄的資料類型與通路權限等。再簡單點,這台MySQL伺服器上,到底有哪些資料庫、各個資料庫有哪些表,每張表的字段類型是什麼,各個資料庫要什麼權限才能通路,等等資訊都儲存在information_schema表裡面。

我們可以用下面三張表來查原因:

       innodb_trx ## 目前運作的所有事務

       innodb_locks ## 目前出現的鎖

       innodb_lock_waits ## 鎖等待的對應關系

如果資料庫中有鎖的話,那麼在

查詢目前運作的事務

       圖中紅色語句為占用系統資源的語句,我們需要殺掉這個鎖,執行 kill 線程id号。上面這條記錄的id為319618246

是以我們執行:kill 319618246即可

執行之後:

執行之後

其他的記錄不需要關注,因為其他的記錄狀态為“RUNNING” 即正在執行的事務,并沒有鎖。。

       我們可以進一步了解一下 那三張表的表結構:

desc information_schema.innodb_locks;

Field     Type     Null     Key     Default     Remark

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     被鎖的資料

desc information_schema.innodb_lock_waits

Field     Type     Null     Key     Default     Remark

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

desc information_schema.innodb_trx ;

Field     Type     Null     Key     Default     Extra     Remark

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         #