mysql檢視死鎖與去除死鎖示例詳解
1、查詢程序
show processlist
2、 查詢到相對應的程序,然後 kill id
驗證(kill後再看是否還有鎖)
2、查詢是否鎖表
show OPEN TABLES where In_use > 0;
示例:
新建一個會話執行如下的顯示鎖示例
LOCK TABLES account_data.account READ; SELECT SLEEP(160); UNLOCK TABLES account_data.account;
另開啟一個會話檢查鎖表情況:
mysql> show OPEN TABLES where In_use > 0; +--------------+---------+--------+-------------+ | Database | Table | In_use | Name_locked | +--------------+---------+--------+-------------+ | account_data | account | 1 | 0 | +--------------+---------+--------+-------------+ 1 row in set (0.00 sec) mysql> select * from information_schema.innodb_locks\G; Empty set,1 warning (0.00 sec) ERROR: No query specified mysql> show processlist\G; *************************** 1. row *************************** Id: 5 User: root Host: 192.168.0.206:64294 db: NULL Command: Sleep Time: 4051 State: Info: NULL *************************** 2. row *************************** Id: 8 User: root Host: 192.168.0.206:64297 db: NULL Command: Sleep Time: 4042 State: Info: NULL *************************** 3. row *************************** Id: 10 User: root Host: localhost db: NULL Command: Query Time: 0 State: starting Info: show processlist *************************** 4. row *************************** Id: 19 User: root Host: 192.168.0.206:54603 db: account_data Command: Sleep Time: 245 State: Info: NULL *************************** 5. row *************************** Id: 20 User: root Host: 192.168.0.206:54604 db: information_schema Command: Query Time: 20 State: User sleep Info: select sleep(160) 5 rows in set (0.00 sec) ERROR: No query specified mysql>
3、在5.5中,information_schema 庫中增加了三個關於鎖的表(innoDB引擎):
innodb_trx ## 當前執行的所有事務
innodb_locks ## 當前出現的鎖
innodb_lock_waits ## 鎖等待的對應關係
先來看一下這三張表結構:
[email protected] : information_schema 13:28:38> 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) [email protected] : information_schema 13:28:56> 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) [email protected] : information_schema 13:29:05> desc innodb_trx ; +—————————-+———————+——+—–+———————+——-+ | 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)
檢視正在鎖的事務
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;
檢視等待鎖的事務
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;
檢視鎖阻塞執行緒資訊
3.1 使用show processlist檢視
3.2 直接使用show engine innodb status檢視
------------ TRANSACTIONS ------------ Trx id counter 4131 Purge done for trx's n:o < 4119 undo n:o < 0 state: running but idle History list length 126 LIST OF TRANSACTIONS FOR EACH SESSION: ---TRANSACTION 0,not started MySQL thread id 2,OS thread handle 0x7f953ffff700,query id 115 localhost root init show engine innodb status ---TRANSACTION 4130,ACTIVE 41 sec starting index read mysql tables in use 1,locked 1 LOCK WAIT 2 lock struct(s),heap size 360,1 row lock(s) MySQL thread id 4,OS thread handle 0x7f953ff9d700,query id 112 localhost root updating delete from emp where empno=7788 ------- TRX HAS BEEN WAITING 41 SEC FOR THIS LOCK TO BE GRANTED: ## 等待了41s RECORD LOCKS space id 16 page no 3 n bits 88 index `PRIMARY` of table `test`.`emp` trx id 4130 lock_mode X locks rec but not gap waiting Record lock,heap no 9 PHYSICAL RECORD: n_fields 10; compact format; info bits 0 ## 執行緒4在等待往test.emp中的主鍵上加X鎖,page num=3 0: len 4; hex 80001e6c; asc l;; 1: len 6; hex 000000001018; asc ;; 2: len 7; hex 91000001420084; asc B ;; 3: len 5; hex 53434f5454; asc SCOTT;; 4: len 7; hex 414e414c595354; asc ANALYST;; 5: len 4; hex 80001d8e; asc ;; 6: len 4; hex 208794f0; asc ;; 7: len 4; hex 80000bb8; asc ;; 8: SQL NULL; 9: len 4; hex 80000014; asc ;; ------------------ ---TRANSACTION 4129,ACTIVE 45 sec starting index read mysql tables in use 1,1 row lock(s) MySQL thread id 7,OS thread handle 0x7f953ff6c700,query id 111 localhost root updating update emp set sal=3500 where empno=7788 ------- TRX HAS BEEN WAITING 45 SEC FOR THIS LOCK TO BE GRANTED: ## 等待了45s RECORD LOCKS space id 16 page no 3 n bits 88 index `PRIMARY` of table `test`.`emp` trx id 4129 lock_mode X locks rec but not gap waiting Record lock,heap no 9 PHYSICAL RECORD: n_fields 10; compact format; info bits 0 ## 執行緒7在等待往test.emp中的主鍵上加X鎖,page num=3 0: len 4; hex 80001e6c; asc l;; 1: len 6; hex 000000001018; asc ;; 2: len 7; hex 91000001420084; asc B ;; 3: len 5; hex 53434f5454; asc SCOTT;; 4: len 7; hex 414e414c595354; asc ANALYST;; 5: len 4; hex 80001d8e; asc ;; 6: len 4; hex 208794f0; asc ;; 7: len 4; hex 80000bb8; asc ;; 8: SQL NULL; 9: len 4; hex 80000014; asc ;; ------------------ ---TRANSACTION 4128,ACTIVE 51 sec 2 lock struct(s),1 row lock(s) MySQL thread id 3,OS thread handle 0x7f953ffce700,query id 110 localhost root cleaning up
我們知道,主要根因還是thread=3引起的,但從innodb status中卻無法分析得到這個結果。
從上面來看,執行緒4和執行緒7都在等待往test.emp中的主鍵上加X鎖,page num=3,但是執行緒7等待的時間為45s,而執行緒4等待的時間為41s,是較執行緒7之後申請的鎖,所以可以判斷是執行緒7阻塞了執行緒4。至於執行緒7為什麼出現等待,這裡分析不到根因。
3.3 使用mysqladmin debug檢視
# mysqladmin -S /tmp/mysql3306.sock debug
然後在error日誌中,會看到:
Thread database.table_name Locked/Waiting Lock_type 3 test.t3 Locked - read Low priority read lock 7 test.emp Locked - write High priority write lock
這種方法中,能找到執行緒ID=3和7是阻塞者,但還是不太準確,判斷不出來執行緒7也是被執行緒ID=3阻塞的。
3.4 使用innodb_lock_monitor來獲取阻塞鎖執行緒
MySQL [test]> CREATE TABLE innodb_lock_monitor (a INT) ENGINE=INNODB; ## 隨便在一個數據庫中建立這個表,就會開啟lock monitor Query OK,0 rows affected,1 warning (0.07 sec) MySQL [test]> show warnings\G *************************** 1. row *************************** Level: Warning Code: 131 Message: Using the table name innodb_lock_monitor to enable diagnostic output is deprecated and may be removed in future releases. Use INFORMATION_SCHEMA or PERFORMANCE_SCHEMA tables or SET GLOBAL innodb_status_output=ON. 1 row in set (0.00 sec)
說明:這個在5.6中有一個warning,但不影響使用。
然後再使用show engine innodb status檢視:
------------ TRANSACTIONS ------------ Trx id counter 4667 Purge done for trx's n:o < 4659 undo n:o < 0 state: running but idle History list length 138 LIST OF TRANSACTIONS FOR EACH SESSION: ---TRANSACTION 0,not started MySQL thread id 9,OS thread handle 0x7f813c5f7700,query id 152 localhost root init show engine innodb status ---TRANSACTION 4663,ACTIVE 78 sec starting index read mysql tables in use 1,OS thread handle 0x7f813c628700,query id 149 localhost root updating delete from emp where empno=7788 ------- TRX HAS BEEN WAITING 78 SEC FOR THIS LOCK TO BE GRANTED: ## 等待了78s RECORD LOCKS space id 16 page no 3 n bits 88 index `PRIMARY` of table `test`.`emp` trx id 4663 lock_mode X locks rec but not gap waiting Record lock,heap no 9 PHYSICAL RECORD: n_fields 10; compact format; info bits 0 ## 執行緒4在等待往test.emp中的主鍵上加X鎖,page num=3 0: len 4; hex 80001e6c; asc l;; 1: len 6; hex 000000001018; asc ;; 2: len 7; hex 91000001420084; asc B ;; 3: len 5; hex 53434f5454; asc SCOTT;; 4: len 7; hex 414e414c595354; asc ANALYST;; 5: len 4; hex 80001d8e; asc ;; 6: len 4; hex 208794f0; asc ;; 7: len 4; hex 80000bb8; asc ;; 8: SQL NULL; 9: len 4; hex 80000014; asc ;; ------------------ TABLE LOCK table `test`.`emp` trx id 4663 lock mode IX ## 在給主鍵行上加X鎖之前,先要在表上加意向鎖IX RECORD LOCKS space id 16 page no 3 n bits 88 index `PRIMARY` of table `test`.`emp` trx id 4663 lock_mode X locks rec but not gap waiting Record lock,heap no 9 PHYSICAL RECORD: n_fields 10; compact format; info bits 0 0: len 4; hex 80001e6c; asc l;; 1: len 6; hex 000000001018; asc ;; 2: len 7; hex 91000001420084; asc B ;; 3: len 5; hex 53434f5454; asc SCOTT;; 4: len 7; hex 414e414c595354; asc ANALYST;; 5: len 4; hex 80001d8e; asc ;; 6: len 4; hex 208794f0; asc ;; 7: len 4; hex 80000bb8; asc ;; 8: SQL NULL; 9: len 4; hex 80000014; asc ;; ---TRANSACTION 4662,ACTIVE 81 sec starting index read mysql tables in use 1,OS thread handle 0x7f813c5c6700,query id 148 localhost root updating update emp set sal=3500 where empno=7788 ------- TRX HAS BEEN WAITING 81 SEC FOR THIS LOCK TO BE GRANTED: ## 等待了81s RECORD LOCKS space id 16 page no 3 n bits 88 index `PRIMARY` of table `test`.`emp` trx id 4662 lock_mode X locks rec but not gap waiting Record lock,heap no 9 PHYSICAL RECORD: n_fields 10; compact format; info bits 0 ## 執行緒7在等待往test.emp中的主鍵上加X鎖,page num=3 0: len 4; hex 80001e6c; asc l;; 1: len 6; hex 000000001018; asc ;; 2: len 7; hex 91000001420084; asc B ;; 3: len 5; hex 53434f5454; asc SCOTT;; 4: len 7; hex 414e414c595354; asc ANALYST;; 5: len 4; hex 80001d8e; asc ;; 6: len 4; hex 208794f0; asc ;; 7: len 4; hex 80000bb8; asc ;; 8: SQL NULL; 9: len 4; hex 80000014; asc ;; ------------------ TABLE LOCK table `test`.`emp` trx id 4662 lock mode IX ## 在給主鍵行上加X鎖之前,先要在表上加意向鎖IX RECORD LOCKS space id 16 page no 3 n bits 88 index `PRIMARY` of table `test`.`emp` trx id 4662 lock_mode X locks rec but not gap waiting Record lock,heap no 9 PHYSICAL RECORD: n_fields 10; compact format; info bits 0 0: len 4; hex 80001e6c; asc l;; 1: len 6; hex 000000001018; asc ;; 2: len 7; hex 91000001420084; asc B ;; 3: len 5; hex 53434f5454; asc SCOTT;; 4: len 7; hex 414e414c595354; asc ANALYST;; 5: len 4; hex 80001d8e; asc ;; 6: len 4; hex 208794f0; asc ;; 7: len 4; hex 80000bb8; asc ;; 8: SQL NULL; 9: len 4; hex 80000014; asc ;; ---TRANSACTION 4615,ACTIVE 1579 sec,thread declared inside InnoDB 1222 mysql tables in use 2,locked 0 2 lock struct(s),OS thread handle 0x7f813c659700,query id 147 localhost root Sending data select count(*) from t3 a,t3 b ## 這是執行緒3當前正在執行的SQL Trx read view will not see trx with id >= 4662,sees < 4659 TABLE LOCK table `test`.`emp` trx id 4615 lock mode IX ## 執行緒3中正在擁有表上的意向IX鎖,並且有test.emp表上主鍵的行級X鎖,page num=3 RECORD LOCKS space id 16 page no 3 n bits 88 index `PRIMARY` of table `test`.`emp` trx id 4615 lock_mode X locks rec but not gap Record lock,heap no 9 PHYSICAL RECORD: n_fields 10; compact format; info bits 0 0: len 4; hex 80001e6c; asc l;; 1: len 6; hex 000000001018; asc ;; 2: len 7; hex 91000001420084; asc B ;; 3: len 5; hex 53434f5454; asc SCOTT;; 4: len 7; hex 414e414c595354; asc ANALYST;; 5: len 4; hex 80001d8e; asc ;; 6: len 4; hex 208794f0; asc ;; 7: len 4; hex 80000bb8; asc ;; 8: SQL NULL; 9: len 4; hex 80000014; asc ;;
為什麼執行緒3當前執行的是一個select t3表操作,但卻鎖住了test.emp表上page num=3?
有可能是執行緒3之前對test.emp表的操作事務沒有及時提交導致。
所以得出:執行緒3阻塞了執行緒7,而執行緒7又阻塞了執行緒4,所以根因就是執行緒3,讓執行緒3儘快提交或是kill掉即可。
3.5、 查看錶鎖的情況:
mysql> show status like 'table%'; +----------------------------+---------+ | Variable_name | Value | +----------------------------+---------+ | Table_locks_immediate | 100 | | Table_locks_waited | 11 | +----------------------------+---------+
3.6、檢視InnoDB_row_lock狀態變數來分析系統上的行鎖的爭奪情況:
mysql> show status like 'InnoDB_row_lock%'; +-------------------------------+--------+ | Variable_name | Value | +-------------------------------+--------+ | Innodb_row_lock_current_waits | 0 | | Innodb_row_lock_time | 159372 | | Innodb_row_lock_time_avg | 39843 | | Innodb_row_lock_time_max | 51154 | | Innodb_row_lock_waits | 4 | +-------------------------------+--------+ 5 rows in set (0.01 sec) mysql>
4. 結論
在分析innodb中鎖阻塞時,幾種方法的對比情況:
(1)使用show processlist檢視不靠譜;
(2)直接使用show engine innodb status檢視,無法判斷到問題的根因;
(3)使用mysqladmin debug檢視,能看到所有產生鎖的執行緒,但無法判斷哪個才是根因;
(4)開啟innodb_lock_monitor後,再使用show engine innodb status檢視,能夠找到鎖阻塞的根因。
參考:https://www.jb51.net/article/201222.htm
到此這篇關於mysql檢視死鎖與去除死鎖的文章就介紹到這了,更多相關mysql檢視死鎖與去除死鎖內容請搜尋我們以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援我們!