2. 程式人生 > 其它 >mysql鎖排查

mysql鎖排查

阿新 • • 發佈：2022-02-16

一、說明

本文將通過實驗介紹mysql鎖該如何排查，本實驗的mysql版本為8.0.23，隔離級別為RC。

二、實驗

場景一：會話a開啟事務，刪除全部資料。會話b開始事務，刪除部分資料

會話A:

(root@localhost)[hello]> begin;
(root@localhost)[hello]> delete from x1;
(root@localhost)[hello]> delete from x2;
(root@localhost)[hello]> select * from x1;
(root@localhost)[hello]> select * from x2;

會話B:

(root@localhost)[hello]> begin;
(root@localhost)[hello]> delete from x1 limit 1;  # 此處發生等待

再起一個視窗，檢視會話列表
ID 34即會話A已執行完成，狀態為Sleep。ID 37即會話B正在執行，狀態為Query。

(root@localhost)[(none)]> select * from information_schema.processlist;
+----+------+-----------+-------+---------+------+-----------+----------------------------------------------+
| ID | USER | HOST      | DB    | COMMAND | TIME | STATE     | INFO                                         |
+----+------+-----------+-------+---------+------+-----------+----------------------------------------------+
| 34 | root | localhost | hello | Sleep   |   49 |           | NULL                                         |
| 36 | root | localhost | NULL  | Query   |    0 | executing | select * from information_schema.processlist |
| 37 | root | localhost | hello | Query   |   12 | updating  | delete from x1 limit 1                       |
+----+------+-----------+-------+---------+------+-----------+----------------------------------------------+

檢視會話阻塞情況，waiting_pid、waiting_trx_id、blocking_pid、blocking_trx_id，分別表示被阻塞的事務和導致阻塞的事務。
結果顯示事務23641阻塞了事務23654。

(root@localhost)[(none)]> select locked_table_schema, locked_table_name, waiting_query, waiting_pid, waiting_trx_id, blocking_pid, blocking_trx_id from sys.innodb_lock_waits;
+---------------------+-------------------+------------------------+-------------+----------------+--------------+-----------------+
| locked_table_schema | locked_table_name | waiting_query          | waiting_pid | waiting_trx_id | blocking_pid | blocking_trx_id |
+---------------------+-------------------+------------------------+-------------+----------------+--------------+-----------------+
| hello               | x1                | delete from x1 limit 1 |          37 |          23654 |           34 |           23641 |
+---------------------+-------------------+------------------------+-------------+----------------+--------------+-----------------+

檢視鎖的資訊，engine_transaction_id對應事務編號，thread_id對應執行緒編號。
前面我們查到事務編號23641阻塞了事務編號23654，這裡顯示事務編號23641對應執行緒85，事務編號23654對應執行緒88。

(root@localhost)[(none)]> select distinct engine_transaction_id, thread_id, object_schema, object_name, lock_type, lock_mode, lock_status from performance_schema.data_locks;
+-----------------------+-----------+---------------+-------------+-----------+---------------+-------------+
| engine_transaction_id | thread_id | object_schema | object_name | lock_type | lock_mode     | lock_status |
+-----------------------+-----------+---------------+-------------+-----------+---------------+-------------+
|                 23654 |        88 | hello         | x1          | TABLE     | IX            | GRANTED     |
|                 23654 |        88 | hello         | x1          | RECORD    | X,REC_NOT_GAP | WAITING     |
|                 23641 |        85 | hello         | x1          | TABLE     | IX            | GRANTED     |
|                 23641 |        85 | hello         | x1          | RECORD    | X,REC_NOT_GAP | GRANTED     |
|                 23641 |        85 | hello         | x2          | TABLE     | IX            | GRANTED     |
|                 23641 |        85 | hello         | x2          | RECORD    | X,REC_NOT_GAP | GRANTED     |
+-----------------------+-----------+---------------+-------------+-----------+---------------+-------------+

檢視造成阻塞的執行緒歷史執行的語句，其中thread_id對應performance_schema.data_locks中的thread_id
結果顯示執行緒85執行過“delete from x1”，這才是執行緒88執行“delete from x1 limit 1”等待的原因。

(root@localhost)[(none)]> select timer_start, thread_id, sql_text, message_text from performance_schema.events_statements_history where event_name like 'statement/sql%' and thread_id in (85) order by timer_start desc;
+-------------------+-----------+----------------------------------+--------------+
| timer_start       | thread_id | sql_text                         | message_text |
+-------------------+-----------+----------------------------------+--------------+
| 22461001917916000 |        85 | select * from x2                 | NULL         |
| 22460129443671000 |        85 | select * from x1                 | NULL         |
| 22460050982468000 |        85 | delete from x2                   | NULL         |
| 22460020034606000 |        85 | delete from x1                   | NULL         |
| 22459990044910000 |        85 | begin                            | NULL         |
| 22416295653612000 |        85 | select USER()                    | NULL         |
| 22416294129231000 |        85 | select @@version_comment limit 1 | NULL         |
+-------------------+-----------+----------------------------------+--------------+

將上面所有的語句進行合併，就可以得到鎖的完整資訊了

(root@localhost)[(none)]> select distinct a.wait_started, a.locked_table, a.waiting_query, a.waiting_pid, a.blocking_pid, c.sql_text 
from sys.innodb_lock_waits a 
join performance_schema.data_locks b on (a.blocking_trx_id = b.engine_transaction_id and a.locked_table_schema = b.object_schema and a.locked_table_name = b.object_name)
join performance_schema.events_statements_history c on (b.thread_id = c.thread_id and c.sql_text regexp b.object_name);
+---------------------+--------------+------------------------+-------------+--------------+------------------+
| wait_started        | locked_table | waiting_query          | waiting_pid | blocking_pid | sql_text         |
+---------------------+--------------+------------------------+-------------+--------------+------------------+
| 2022-02-16 16:26:25 | `hello`.`x1` | delete from x1 limit 1 |          37 |           34 | delete from x1   |
| 2022-02-16 16:26:25 | `hello`.`x1` | delete from x1 limit 1 |          37 |           34 | select * from x1 |
+---------------------+--------------+------------------------+-------------+--------------+------------------+

場景二：會話a對錶加元資料鎖。會話b開始事務，刪除部分資料

會話A:

(root@localhost)[hello]> lock table x1 write;

會話B:

(root@localhost)[hello]> delete from x1 limit 1;  # 此處發生等待

檢視會話列表
ID 39即會話A已執行完成，狀態為Sleep。ID 40即會話B正在執行，狀態為Query。

(root@localhost)[(none)]> select * from information_schema.processlist;
+----+------+-----------+-------+---------+------+---------------------------------+----------------------------------------------+
| ID | USER | HOST      | DB    | COMMAND | TIME | STATE                           | INFO                                         |
+----+------+-----------+-------+---------+------+---------------------------------+----------------------------------------------+
| 49 | root | localhost | hello | Sleep   |   81 |                                 | NULL                                         |
| 51 | root | localhost | NULL  | Query   |    0 | executing                       | select * from information_schema.processlist |
| 52 | root | localhost | hello | Query   |    9 | Waiting for table metadata lock | delete from x1 limit 1                       |
+----+------+-----------+-------+---------+------+---------------------------------+----------------------------------------------+

檢視innodb_lock_waits和data_locks，都沒有資料。

(root@localhost)[(none)]> select * from sys.innodb_lock_waits;
Empty set (0.00 sec)

(root@localhost)[(none)]> select * from performance_schema.data_locks;
Empty set (0.00 sec)

檢視當前資料庫執行過的sql，能找到鎖表的語句，注意這裡的thread_id並不對應processlist表中的id。

(root@localhost)[(none)]> select thread_id, event_name, sql_text from performance_schema.events_statements_current;
+-----------+---------------------------+------------------------------------------------------------------------------------------+
| thread_id | event_name                | sql_text                                                                                 |
+-----------+---------------------------+------------------------------------------------------------------------------------------+
|       100 | statement/sql/lock_tables | lock table x1 write                                                                      |
|       102 | statement/sql/select      | select thread_id, event_name, sql_text from performance_schema.events_statements_current |
|       103 | statement/sql/delete      | delete from x1 limit 1                                                                   |
+-----------+---------------------------+------------------------------------------------------------------------------------------+

檢視threads表，這裡的thread_id對應events_statements_current表中thread_id，processlist_id對應processlist表中id。

(root@localhost)[(none)]> select thread_id, processlist_id, processlist_user, processlist_db, processlist_command, processlist_time, processlist_state, processlist_info from performance_schema.threads where type = 'FOREGROUND';
+-----------+----------------+------------------+----------------+---------------------+------------------+---------------------------------+------------------------+
| thread_id | processlist_id | processlist_user | processlist_db | processlist_command | processlist_time | processlist_state               | processlist_info       |
+-----------+----------------+------------------+----------------+---------------------+------------------+---------------------------------+------------------------+
|        48 |              6 | NULL             | NULL           | Daemon              |            31219 | Suspending                      | NULL                   |
|       100 |             49 | root             | hello          | Sleep               |              172 | NULL                            | NULL                   |
|       103 |             52 | root             | hello          | Query               |              100 | Waiting for table metadata lock | delete from x1 limit 1 |
+-----------+----------------+------------------+----------------+---------------------+------------------+---------------------------------+------------------------+

將以上sql進行合併，從sql_text中找鎖表的語句，殺掉對應的會話即可。

(root@localhost)[(none)]> select b.processlist_id, b.processlist_user, b.processlist_db, b.processlist_command, b.processlist_time, b.processlist_state, b.processlist_info, a.event_name, a.sql_text
from performance_schema.events_statements_current a
join performance_schema.threads b on (a.thread_id = b.thread_id);
+----------------+------------------+----------------+---------------------+------------------+---------------------------------+-------------------------+---------------------------+------------------------+
| processlist_id | processlist_user | processlist_db | processlist_command | processlist_time | processlist_state               | processlist_info        | event_name                | sql_text               |
+----------------+------------------+----------------+---------------------+------------------+---------------------------------+-------------------------+---------------------------+------------------------+
|             49 | root             | hello          | Sleep               |              289 | NULL                            | NULL                    | statement/sql/lock_tables | lock table x1 write    |
|             52 | root             | hello          | Query               |              217 | Waiting for table metadata lock | delete from x1 limit 1  | statement/sql/delete      | delete from x1 limit 1 |
+----------------+------------------+----------------+---------------------+------------------+---------------------------------+-------------------------+---------------------------+------------------------+

三、監控

檢視事務資訊

(root@localhost)[(none)]> select trx_id, trx_state, trx_started, trx_mysql_thread_id, trx_query from information_schema.innodb_trx;
+--------+-----------+---------------------+---------------------+------------------------+
| trx_id | trx_state | trx_started         | trx_mysql_thread_id | trx_query              |
+--------+-----------+---------------------+---------------------+------------------------+
|  23654 | LOCK WAIT | 2022-02-16 16:26:25 |                  37 | delete from x1 limit 1 |
|  23641 | RUNNING   | 2022-02-16 16:25:47 |                  34 | NULL                   |
+--------+-----------+---------------------+---------------------+------------------------+

因此可以通過下面的語句查出當前最長的事務。

(root@localhost)[(none)]> select max(time_to_sec(timediff(now(), trx_started))) max_trx_time from information_schema.innodb_trx;  
+--------------+
| max_trx_time |
+--------------+
|          571 |
+--------------+

四、總結

  1. 等待行鎖最大的等待時長引數為innodb_lock_wait_timeout，預設50s。等待元資料鎖最大的等待時長引數為lock_wait_timeout，預設31536000s（一年）。建議對lock_wait_timeout進行調整。
  2. 通過information_schema.innodb_trx對資料庫進行長事務監控。
  3. 通過sys.innodb_lock_waits檢視被阻塞的sql
  4. 元資料鎖通過performance_schema.events_statements_current，performance_schema.threads關聯起來看

相關推薦

mysql鎖排查

一、說明 本文將通過實驗介紹mysql鎖該如何排查，本實驗的mysql版本為8.0.23，隔離級別為RC。

一次神奇的MySQL死鎖排查記錄

背景 說起Mysql死鎖，之前寫過一次有關Mysql加鎖的基本介紹，對於一些基本的Mysql鎖或者死鎖都有一個簡單的認識，可以看下這篇文章為什麼開發人員需要了解資料庫鎖。有了上面的經驗之後，本以為對於死鎖都能手到擒來

MySQL一次死鎖排查過程分析（雙update）

1.環境 MySQL5.7.26，事務隔離級別為RR 2.表結構 +------------------+------------------+------+-----+---------------------+----------------+

MySql 鎖表問題排查

innodb_trx表：trx_id：事務ID。trx_state：事務狀態，有以下幾種狀態：RUNNING、LOCK WAIT、ROLLING BACK 和 COMMITTING。trx_started：事務開始時間。trx_requested_lock_id：事務當前正在等待鎖的標識，可以和 I

MySQL死鎖排查（轉載）

在深入探究問題之前，我們先了解一下 MySQL 的加鎖機制。 一、MySQL 加鎖機制 首先要明確的一點是 MySQL 加鎖實際上是給索引加鎖，而非給資料加鎖。我們先看下MySQL 索引的結構。

mysql 死鎖排查及處理

1、 檢視當前被鎖的表show OPEN TABLES where In_use > 0;+----------+-------+--------+-------------+| Database | Table | In_use | Name_locked |+----------+-------+--------+-------------+| MyDB| tb_xx|

mysql 死鎖排查

select * from information_schema.innodb_trx; trx_id：唯一事務id號，只讀事務和非鎖事務是不會建立id的。

再談mysql鎖機制及原理—鎖的詮釋

加鎖是實現資料庫併發控制的一個非常重要的技術。當事務在對某個資料物件進行操作前，先向系統發出請求，對其加鎖。加鎖後事務就對該資料物件有了一定的控制，在該事務釋放鎖之前，其他的事務不能對此資料物件進行更

MySQL鎖的知識點總結

鎖的概念 ①、鎖，在現實生活中是為我們想要隱藏於外界所使用的一種工具。

MySQL鎖(表鎖,行鎖,共享鎖,排它鎖,間隙鎖)使用詳解

鎖，在現實生活中是為我們想要隱藏於外界所使用的一種工具。在計算機中，是協調多個程序或縣城併發訪問某一資源的一種機制。在資料庫當中，除了傳統的計算資源（CPU、RAM、I/O等等）的爭用之外，資料也是一種供許多使

sql server中死鎖排查的全過程分享

前言 記得以前客戶在使用軟體時，有偶發出現死鎖問題，因為發生的時間不確定，不好做問題的重現，當時解決問題有點棘手了。

MySQL鎖機制與用法分析

本文例項講述了MySQL鎖機制與用法。分享給大家供大家參考，具體如下： MySQL的鎖機制比較簡單，其最顯著的特點是不同的儲存引擎支援不同的鎖機制。比如，MyISAM和MEMORY儲存引擎採用的是表級鎖；BDB儲存引擎採用的是

MySQL複習（二）：MySQL鎖、MySQL事務、SQL優化、資料庫分庫分表

五、MySQL鎖 根據加鎖的範圍，MySQL裡面的鎖大致可以分成全域性鎖、表級鎖和行鎖三類

JAVA死鎖排查-效能測試問題排查思路

死鎖原因 Java發生死鎖的根本原因是：在申請鎖時發生了交叉閉環申請。即執行緒在獲得了鎖A並且沒有釋放的情況下去申請鎖B，這時，另一個執行緒已經獲得了鎖B，在釋放鎖B之前又要先獲得鎖A，因此閉環發生，陷入死鎖迴

mysql所排查思路

檢視是否有鎖現象 ## 1. 看有沒有鎖等待 SHOWSTATUS LIKE \'innodb_row_lock%\'; ## 2. 檢視哪個事務在等待(被阻塞了)

MySQL 鎖資訊檢視

事務 -- 檢視當前所有事務 select * from information_schema.innodb_trx; -- 檢視正在鎖的事務

mysql鎖的理解

Alocking read, anUPDATE, or aDELETEgenerally set record locks on every index record that is scanned in the processing of the SQL statement. It does not matter whether there areWHEREconditions in the s

mysql鎖大全【轉】

轉自：連結 引言 大家在面試中有沒遇到面試官問你下面六句Sql的區別呢 select * from table where id = ?

mysql鎖官方文件與理解之InnoDB鎖

This section describes lock types used byInnoDB. 翻譯：本節描述了InnoDB使用的鎖型別。 Shared and Exclusive Locks（共享鎖和排他鎖）

簡單理解MySQL鎖

簡單理解MySQL鎖 前段時間看一些面經，感覺自己MySQL鎖這一塊知識很零碎，決定系統地記錄一下。