欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

一文詳細講解如何查看mysql里面的鎖

 更新時間：2023年11月14日 11:29:02   作者：神族依戀  
鎖是MySQL里面最難理解的知識,但是又無處不在,下面這篇文章主要給大家介紹了關于關于如何查看mysql里面鎖的相關資料,文中通過代碼介紹的非常詳細,需要的朋友可以參考下

通過查詢表統(tǒng)計信息查看

information_schema庫下相關事務表和鎖相關信息表介紹

innodb_trx

存儲了當前正在執(zhí)行的事務信息

trx_id：事務ID。

trx_state：事務狀態(tài)，有以下幾種狀態(tài)：RUNNING、LOCK WAIT、ROLLING BACK 和 COMMITTING。

trx_started：事務開始時間。

trx_requested_lock_id：事務當前正在等待鎖的標識，可以和 INNODB_LOCKS 表 JOIN 以得到更多詳細信息。

trx_wait_started：事務開始等待的時間。

trx_mysql_thread_id：事務線程 ID，可以和 PROCESSLIST 表 JOIN。

trx_tables_locked：表示該事務目前加了多少個表級鎖。

trx_lock_structs：表示該事務生成了多少個內存中的鎖結構。

trx_lock_memory_bytes：事務鎖住的內存大小，單位為 BYTES。

trx_rows_locked：表示該事務目前加了多少個行級鎖。

innodb_locks

記錄了鎖信息

如果一個事務想要獲取到某個鎖但未獲取到，則記錄該鎖信息

如果一個事務獲取到了某個鎖，但是這個鎖阻塞了別的事務，則記錄該鎖信息

但是無法通過該表查詢到誰被阻塞，誰持有未釋放。

lock_id：鎖 ID。

lock_trx_id：擁有鎖的事務 ID?？梢院?INNODB_TRX 表 JOIN 得到事務的詳細信息。

lock_mode：鎖的模式。

lock_type：鎖的類型。RECORD 代表行級鎖，TABLE 代表表級鎖。

lock_table：被鎖定的或者包含鎖定記錄的表的名稱。

innodb_lock_waits

表明每個阻塞的事務是因為獲取不到哪個事務持有的鎖而被阻塞

requesting_trx_id：–獲取不到鎖而被阻塞的事務id（等待方）

requested_lock_id：-- 請求鎖ID ，事務所等待的鎖定的 ID?？梢院?INNODB_LOCKS 表 JOIN。

blocking_trx_id： --獲取到別的事務需要的鎖而阻塞其事務的事務id（當前持有方，待釋放）

blocking_lock_id： --這一事務的鎖的 ID，該事務阻塞了另一事務的運行?？梢院?INNODB_LOCKS 表 JOIN。

processlist

id:標識ID。這與在SHOW PROCESSLIST語句的Id列、Performance Schema threads表的PROCESSLIST_ID列中顯示的值類型相同，并由CONNECTION_ID()函數返回

user:發(fā)出該語句的mysql用戶。

host：發(fā)出該語句的客戶機的主機名(系統(tǒng)用戶除外，沒有主機)。

db：默認數據庫。

command：線程正在執(zhí)行的命令的類型。

time：線程處于當前狀態(tài)的時間(以秒為單位)。

state：指示線程正在執(zhí)行的操作、事件或狀態(tài)。

info：線程正在執(zhí)行的語句，如果沒有執(zhí)行任何語句，則為NULL。

如何借助這幾張表來定位到有行鎖等待

（1）查看當前有無鎖等待

mysql> show status like ‘innodb_row_lock%’;

（2）查看哪個事務在等待(被阻塞了)

mysql> select * from information_schema.INNODB_TRX WHERE trx_state='LOCK WAIT'\G
trx_state 表示該事務處于鎖等待狀態(tài)。
trx_query : 當前被阻塞的操作是select * from actor where actor_id=1 for update。
從trx_mysql_thread_id和trx_id可以看到這里查到當前被阻塞的事務的：
線程ID是 971，注意說的是線程id

事務ID是3934

（3）查詢該事務被哪個事務給阻塞了

從innodb_trx獲取到被阻塞的trx_id是3934，阻塞該事務的事務id是3933

mysql> SELECT * FROM performance_schema.threads WHERE processlist_id=970\G

（4）根據trx_id，從innodb_trx表可查詢到trx_mysql_thread_id線程id為970

mysql> select * from information_schema.innodb_trx where trx_id=3933 \G

（5）根據線程id，查詢表拿到thread_id為995

mysql> SELECT * FROM performance_schema.threads WHERE processlist_id=970\G

（6）根據thread_id，查詢當前鎖源的sql

整個流程如下：

（1）首先查詢是否有鎖，根據鎖查到被鎖的trx_id

（2）根據被鎖的trx_id可以查到鎖源的trx_id

（3）根據鎖源的trx_id查到trx_mysql_thread_id

（4）再根據trx_mysql_thread_id查到thread_id

（5）最后，用thread_id查找到鎖源的sql

此外，第一步發(fā)現(xiàn)鎖的方式，也可直接獲取到鎖源trx_id和被鎖trx_id

但是這種方法在mysql8.0已經被移除，介紹另外一張表

sys.innodb_lock_waits 表

  • locked_table : 哪張表出現(xiàn)的等待
  • waiting_trx_id: 等待的事務(與上個視圖trx_id 對應)
  • waiting_pid : 等待的線程號(與上個視圖trx_mysql_thread_id)
  • blocking_trx_id : 鎖源的事務ID
  • blocking_pid : 鎖源的線程號

mysql> select * from sys.innodb_lock_waits\G

獲取到鎖源的blocking_pid 976（=processlist表的id），根據此id找到thread_id，再根據thread_id找到對應的sql

總結：

兩種找到鎖源SQL步驟是一樣的

鎖源的事務trx_id -->pnformaction_schema.processlist表的線程id–>performance_schema.threads表的thread_id–>performance_schema.events_statements_current 或performance_schema.events_statements_history查看sql

注：下面所指的id含義相同

information_schema.innodb_trx(trx_mysql_thread_id)

information_schema.processlist(id)

sys.innodb_lock_waits(waiting_pid,blocking_pid)

sys.sys.innodb_lock_waits的應用

1）查看鎖等待相關的（阻塞線程、被阻塞線程信息及相關用戶、IP、PORT、locked_type鎖類型）
SELECT locked_table,
       locked_index,
       locked_type,
       blocking_pid,
       concat(T2.USER,'@',T2.HOST) AS "blocking(user@ip:port)",
       blocking_lock_mode,
       blocking_trx_rows_modified,
       waiting_pid,
       concat(T3.USER,'@',T3.HOST) AS "waiting(user@ip:port)",
       waiting_lock_mode,
       waiting_trx_rows_modified,
       wait_age_secs,
       waiting_query
FROM sys.x$innodb_lock_waits T1
LEFT JOIN INFORMATION_SCHEMA.processlist T2 ON T1.blocking_pid=T2.ID
LEFT JOIN INFORMATION_SCHEMA.processlist T3 ON T3.ID=T1.waiting_pid;

2）等待的持續(xù)時間（單位秒>20s）

 SELECT trx_mysql_thread_id AS PROCESSLIST_ID,
       NOW(),
       TRX_STARTED,
       TO_SECONDS(now())-TO_SECONDS(trx_started) AS TRX_LAST_TIME ,
       USER,
       HOST,
       DB,
       TRX_QUERY
FROM INFORMATION_SCHEMA.INNODB_TRX trx
JOIN sys.innodb_lock_waits lw ON trx.trx_mysql_thread_id=lw.waiting_pid
JOIN INFORMATION_SCHEMA.processlist pcl ON trx.trx_mysql_thread_id=pcl.id
WHERE trx_mysql_thread_id != connection_id()
  AND TO_SECONDS(now())-TO_SECONDS(trx_started) >= 20 ;
show engine innodb status
將鎖信息打印出來

mysql> set global innodb_status_output_locks =ON;

執(zhí)行如下sql，fisrt_name上有普通二級索引

begin;

select * from actor where first_name >'A' and first_name <'B' for update; 查詢得到該事務ID，方面后面觀察驗證

show engine innodb status看到的事務信息如下

我將注釋寫在#后面

TRANSACTIONS

Trx id counter 3957                                                          #下一個待分配的事務id
Purge done for trx's n:o < 3930 undo n:o < 0 state: running but idle
History list length 0
LIST OF TRANSACTIONS FOR EACH SESSION:                                       #各個事務信息
---TRANSACTION 421799341399664, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 421799341400576, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 421799341403312, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 421799341398752, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 3956, ACTIVE 25 sec                                           #事務id為3956的事務，活躍時間25秒
3 lock struct(s), heap size 1136, 27 row lock(s)
MySQL thread id 991, OS thread handle 140323910289152, query id 10636 localhost root
TABLE LOCK table `sakila`.`actor` trx id 3956 lock mode IX                  #事務id為3956的事務，對`sakila`.`actor`加了表級別意向獨占鎖 IX
RECORD LOCKS space id 45 page no 5 n bits 272 index idx_actor_first of table `sakila`.`actor` trx id 3956 lock_mode X
Record lock, heap no 2 PHYSICAL RECORD: n_fields 2; compact format; info bits 0    #idx_actor_first 是二級索引，lock_mode X Record lock 表示X型的next_key 鎖
 0: len 4; hex 4144414d; asc ADAM;;
 1: len 2; hex 0047; asc  G;;

Record lock, heap no 3 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 4; hex 4144414d; asc ADAM;;
 1: len 2; hex 0084; asc   ;;

Record lock, heap no 4 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 2; hex 414c; asc AL;;
 1: len 2; hex 00a5; asc   ;;

Record lock, heap no 5 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 4; hex 414c414e; asc ALAN;;
 1: len 2; hex 00ad; asc   ;;

Record lock, heap no 6 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 6; hex 414c42455254; asc ALBERT;;
 1: len 2; hex 007d; asc  };;

Record lock, heap no 7 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 6; hex 414c42455254; asc ALBERT;;
 1: len 2; hex 0092; asc   ;;

Record lock, heap no 8 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 4; hex 414c4543; asc ALEC;;
 1: len 2; hex 001d; asc   ;;

Record lock, heap no 9 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 6; hex 414e47454c41; asc ANGELA;;
 1: len 2; hex 0041; asc  A;;

Record lock, heap no 10 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 6; hex 414e47454c41; asc ANGELA;;
 1: len 2; hex 0090; asc   ;;

Record lock, heap no 11 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 8; hex 414e47454c494e41; asc ANGELINA;;
 1: len 2; hex 004c; asc  L;;

Record lock, heap no 12 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 4; hex 414e4e45; asc ANNE;;
 1: len 2; hex 0031; asc  1;;

Record lock, heap no 13 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 6; hex 415544524559; asc AUDREY;;
 1: len 2; hex 0022; asc  ";;

Record lock, heap no 14 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 6; hex 415544524559; asc AUDREY;;
 1: len 2; hex 00be; asc   ;;

Record lock, heap no 15 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 4; hex 42454c41; asc BELA;;
 1: len 2; hex 00c4; asc   ;;

RECORD LOCKS space id 45 page no 3 n bits 272 index PRIMARY of table `sakila`.`actor` trx id 3956 lock_mode X locks rec but not gap
Record lock, heap no 30 PHYSICAL RECORD: n_fields 6; compact format; info bits 0       # trx id 3956 聚簇索引PRIMARY ，lock_mode X locks rec but not gap Record lock 表示X型記錄鎖
 0: len 2; hex 001d; asc   ;;
 1: len 6; hex 000000000ef8; asc       ;;
 2: len 7; hex cf0000032b0228; asc     + (;;
 3: len 4; hex 414c4543; asc ALEC;;
 4: len 5; hex 5741594e45; asc WAYNE;;
 5: len 4; hex 43f23ed9; asc C > ;;

Record lock, heap no 35 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
 0: len 2; hex 0022; asc  ";;
 1: len 6; hex 000000000ef8; asc       ;;
 2: len 7; hex cf0000032b025a; asc     + Z;;
 3: len 6; hex 415544524559; asc AUDREY;;
 4: len 7; hex 4f4c4956494552; asc OLIVIER;;
 5: len 4; hex 43f23ed9; asc C > ;;

Record lock, heap no 50 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
 0: len 2; hex 0031; asc  1;;
 1: len 6; hex 000000000ef8; asc       ;;
 2: len 7; hex cf0000032b02f0; asc     +  ;;
 3: len 4; hex 414e4e45; asc ANNE;;
 4: len 6; hex 43524f4e594e; asc CRONYN;;
 5: len 4; hex 43f23ed9; asc C > ;;

Record lock, heap no 66 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
 0: len 2; hex 0041; asc  A;;
 1: len 6; hex 000000000ef8; asc       ;;
 2: len 7; hex cf0000032b0390; asc     +  ;;
 3: len 6; hex 414e47454c41; asc ANGELA;;
 4: len 6; hex 485544534f4e; asc HUDSON;;
 5: len 4; hex 43f23ed9; asc C > ;;

Record lock, heap no 72 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
 0: len 2; hex 0047; asc  G;;
 1: len 6; hex 000000000ef8; asc       ;;
 2: len 7; hex cf0000032b03cc; asc     +  ;;
 3: len 4; hex 4144414d; asc ADAM;;
 4: len 5; hex 4752414e54; asc GRANT;;
 5: len 4; hex 43f23ed9; asc C > ;;

Record lock, heap no 77 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
 0: len 2; hex 004c; asc  L;;
 1: len 6; hex 000000000ef8; asc       ;;
 2: len 7; hex cf0000032b03fe; asc     +  ;;
 3: len 8; hex 414e47454c494e41; asc ANGELINA;;
 4: len 7; hex 41535441495245; asc ASTAIRE;;
 5: len 4; hex 43f23ed9; asc C > ;;

Record lock, heap no 126 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
 0: len 2; hex 007d; asc  };;
 1: len 6; hex 000000000ef8; asc       ;;
 2: len 7; hex cf0000032b05e8; asc     +  ;;
 3: len 6; hex 414c42455254; asc ALBERT;;
 4: len 5; hex 4e4f4c5445; asc NOLTE;;
 5: len 4; hex 43f23ed9; asc C > ;;

Record lock, heap no 133 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
 0: len 2; hex 0084; asc   ;;
 1: len 6; hex 000000000ef8; asc       ;;
 2: len 7; hex cf0000032b0631; asc     + 1;;
 3: len 4; hex 4144414d; asc ADAM;;
 4: len 6; hex 484f50504552; asc HOPPER;;
 5: len 4; hex 43f23ed9; asc C > ;;

Record lock, heap no 145 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
 0: len 2; hex 0090; asc   ;;
 1: len 6; hex 000000000ef8; asc       ;;
 2: len 7; hex cf0000032b06b5; asc     +  ;;
 3: len 6; hex 414e47454c41; asc ANGELA;;
 4: len 11; hex 57495448455253504f4f4e; asc WITHERSPOON;;
 5: len 4; hex 43f23ed9; asc C > ;;

Record lock, heap no 147 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
 0: len 2; hex 0092; asc   ;;
 1: len 6; hex 000000000ef8; asc       ;;
 2: len 7; hex cf0000032b06cb; asc     +  ;;
 3: len 6; hex 414c42455254; asc ALBERT;;
 4: len 9; hex 4a4f48414e53534f4e; asc JOHANSSON;;
 5: len 4; hex 43f23ed9; asc C > ;;

Record lock, heap no 166 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
 0: len 2; hex 00a5; asc   ;;
 1: len 6; hex 000000000ef8; asc       ;;
 2: len 7; hex cf0000032b079c; asc     +  ;;
 3: len 2; hex 414c; asc AL;;
 4: len 7; hex 4741524c414e44; asc GARLAND;;
 5: len 4; hex 43f23ed9; asc C > ;;

Record lock, heap no 174 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
 0: len 2; hex 00ad; asc   ;;
 1: len 6; hex 000000000ef8; asc       ;;
 2: len 7; hex cf0000032b07f4; asc     +  ;;
 3: len 4; hex 414c414e; asc ALAN;;
 4: len 8; hex 4452455946555353; asc DREYFUSS;;
 5: len 4; hex 43f23ed9; asc C > ;;

Record lock, heap no 191 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
 0: len 2; hex 00be; asc   ;;

 1: len 6; hex 000000000ef8; asc       ;;
 2: len 7; hex cf0000032b08af; asc     +  ;;
 3: len 6; hex 415544524559; asc AUDREY;;
 4: len 6; hex 4241494c4559; asc BAILEY;;
 5: len 4; hex 43f23ed9; asc C > ;;
從上我們可以看到此事務在表actor上，加上了

mysql> select * from actor where first_name >'A' and first_name <'B' for update;
+----------+------------+-------------+---------------------+
| actor_id | first_name | last_name   | last_update         |
+----------+------------+-------------+---------------------+
|       71 | ADAM       | GRANT       | 2006-02-15 04:34:33 |
|      132 | ADAM       | HOPPER      | 2006-02-15 04:34:33 |
|      165 | AL         | GARLAND     | 2006-02-15 04:34:33 |
|      173 | ALAN       | DREYFUSS    | 2006-02-15 04:34:33 |
|      125 | ALBERT     | NOLTE       | 2006-02-15 04:34:33 |
|      146 | ALBERT     | JOHANSSON   | 2006-02-15 04:34:33 |
|       29 | ALEC       | WAYNE       | 2006-02-15 04:34:33 |
|       65 | ANGELA     | HUDSON      | 2006-02-15 04:34:33 |
|      144 | ANGELA     | WITHERSPOON | 2006-02-15 04:34:33 |
|       76 | ANGELINA   | ASTAIRE     | 2006-02-15 04:34:33 |
|       49 | ANNE       | CRONYN      | 2006-02-15 04:34:33 |
|       34 | AUDREY     | OLIVIER     | 2006-02-15 04:34:33 |
|      190 | AUDREY     | BAILEY      | 2006-02-15 04:34:33 |
+----------+------------+-------------+---------------------+
13 rows in set (0.00 sec)| actor | 

CREATE TABLE `actor` (
  `actor_id` smallint(5) unsigned NOT NULL AUTO_INCREMENT,
  `first_name` varchar(45) NOT NULL,
  `last_name` varchar(45) NOT NULL,
  `last_update` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`actor_id`),
  KEY `idx_actor_last_name` (`last_name`),
  KEY `idx_actor_first` (`first_name`)
) ENGINE=InnoDB AUTO_INCREMENT=201 DEFAULT CHARSET=utf8mb4 |
這些行對應的二級索引idx_actor_first加上了X型next_key鎖，在對應的聚簇索引上加上了X型record鎖

lock_mode X locks gap before rec  表示X型gap鎖
lock mode X                       表示X型next_key 鎖
lock_mode X locks rec but no gap  表示X型record鎖

以上就是mysql查詢鎖信息的兩種方法。

到此這篇關于如何查看mysql里面的鎖的文章就介紹到這了,更多相關mysql查看鎖內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

相關文章

  • MySQL優(yōu)化案例系列-mysql分頁優(yōu)化

    MySQL優(yōu)化案例系列-mysql分頁優(yōu)化

    這篇文章主要介紹了MySQL優(yōu)化案例系列-mysql分頁優(yōu)化,需要的朋友可以參考下
    2016-08-08
  • Mysql中JDBC的三種查詢(普通、流式、游標)詳解

    Mysql中JDBC的三種查詢(普通、流式、游標)詳解

    這篇文章主要介紹了Mysql中JDBC的三種查詢(普通、流式、游標)詳解,JDBC(Java DataBase Connectivity：java數據庫連接)是一種用于執(zhí)行SQL語句的Java API，可以為多種關系型數據庫提供統(tǒng)一訪問，它是由一組用Java語言編寫的類和接口組成的,需要的朋友可以參考下
    2023-08-08
  • mysql隨機查詢若干條數據的方法

    mysql隨機查詢若干條數據的方法

    這篇文章主要介紹了mysql中獲取隨機內容的方法，需要的朋友可以參考下
    2013-10-10
  • MySQL之存在則更新,否則就插入數據

    MySQL之存在則更新,否則就插入數據

    這篇文章主要介紹了MySQL之存在則更新,否則就插入數據問題,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教
    2024-01-01
  • MySQL?中常見的幾種高可用架構部署方案解析

    MySQL?中常見的幾種高可用架構部署方案解析

    MySQL Replication 是官方提供的主從同步方案，用于將一個 MySQL 的實例同步到另一個實例中，這篇文章主要介紹了MySQL?中常見的幾種高可用架構部署方案,需要的朋友可以參考下
    2023-04-04
  • MYSQL與SQLserver之間存儲過程的轉換方式

    MYSQL與SQLserver之間存儲過程的轉換方式

    這篇文章主要介紹了MYSQL與SQLserver之間存儲過程的轉換方式，具有很好的參考價值，希望對大家有所幫助。如有錯誤或未考慮完全的地方，望不吝賜教
    2022-11-11
  • 關于MySQL中explain工具的使用

    關于MySQL中explain工具的使用

    這篇文章主要介紹了關于MySQL中explain工具的使用,在select語句之前增加explain關鍵字，MySQL會在查詢上設置一個標記，執(zhí)行查詢會返回執(zhí)行計劃的信息，而不是執(zhí)行這條SQL,需要的朋友可以參考下
    2023-05-05
  • MySQL中字段類型char、varchar和text的區(qū)別

    MySQL中字段類型char、varchar和text的區(qū)別

    今天小編就為大家分享一篇關于MySQL中字段類型char、varchar和text的區(qū)別，小編覺得內容挺不錯的，現(xiàn)在分享給大家，具有很好的參考價值，需要的朋友一起跟隨小編來看看吧
    2019-03-03
  • deepin 2014系統(tǒng)下安裝mysql數據庫的方法步驟

    deepin 2014系統(tǒng)下安裝mysql數據庫的方法步驟

    這篇文章主要給大家介紹了在deepin 2014系統(tǒng)下安裝mysql數據庫的方法步驟，文中通過圖文介紹的非常詳細，相信對大家具有一定的參考價值，需要的朋友們下面來一起看看吧。
    2017-04-04
  • Mysql中通過生日計算年齡的多種方法

    Mysql中通過生日計算年齡的多種方法

    本文給大家分享mysql通過生日計算年齡的方法，每一種方法都非常不錯，需要的朋友參考下吧
    2018-03-03

最新評論