mysql死鎖排查

阿新 • • 發佈：2018-10-31

死鎖

show engine innodb status;顯示引擎引數,查死鎖sql
show engine innodb mutex;

LATEST DETECTED DEADLOCK
------------------------
2017-01-21 23:00:32 2b4ad8705700
*** (1) TRANSACTION:
TRANSACTION 74247262250, ACTIVE 0 sec starting index read
mysql tables in use 2, locked 2
LOCK WAIT 8 lock struct(s), heap size 
 1184, 7 row lock(s)
MySQL thread id 4808396, OS thread handle 0x2b4a72923700, query id 77966678624 10.150.135.191 cbu_cms Sending data
update   pool_offer t1, pool_offer_batch t2 set t1.score=t2.score where   t1.pool_id=t2.pool_id and t1.offer_id=t2.offer_id and   t2.batch_id='ichoose-221556405-1484989224443' 

*** (1) HOLDS THE LOCK(S):
RECORD LOCKS space id 566 page no 107635 n bits 464 index `ind_pidoid` of table `cbu_cms`.`pool_offer` trx id 74247262250 lock_mode X locks rec but not gap
Record lock, heap no 220 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 8; hex 0000000000004acf; asc       J ;;
 1: len 8; hex 0000000039f5e41c; asc     9   ;;
 2: len 8; hex 0000000003f74e7c; asc       N|;;

*** (1) WAITING FOR THIS LOCK 
 TO BE GRANTED:
RECORD LOCKS space id 566 page no 107635 n bits 464 index `ind_pidoid` of table `cbu_cms`.`pool_offer` trx id 74247262250 lock_mode X locks rec but not gap waiting
Record lock, heap no 337 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 8; hex 0000000000004acf; asc       J ;;
 1: len 8; hex 000000003d236748; asc     =#gH;;
 2: len 8; hex 0000000003fabe1d; asc         ;;

*** (2) TRANSACTION:
TRANSACTION 74247262209, ACTIVE 0 sec inserting, thread declared inside InnoDB 4685
mysql tables in use 2, locked 1
45 lock struct(s), heap size 6544, 159 row lock(s), undo log entries 80
MySQL thread id 4808449, OS thread handle 0x2b4ad8705700, query id 77966678347 11.136.33.169 cbu_cms Creating sort index
insert into pool_offer   (enter_way,gmt_create,gmt_modified,pool_id,offer_id,member_id,category_id,category1_id,category2_id,category3_id,bu_id,expired_time,offerstatus,sort,gmt_sort,status,ds_tag,location)   select 'dsimport' as   enter_way,gmt_create,gmt_modified,pool_id,offer_id,member_id,category_id,category1_id,category2_id,category3_id,bu_id,expired_time,offerstatus,sort,gmt_modified,'NORMAL'   as status,ds_tag,location from pool_offer_batch   where batch_id='import-offer-25767666-1484989291643' and   pool_id=19151 order by id   on duplicate key   update   gmt_modified=now(),gmt_sort=values(gmt_modified),sort=values(sort),   expired_time=values(expired_time),offerstatus=values(offerstatus),ds_tag=values(ds_tag),   location = values(location),   category_id = values(category_id),   category1_id = values(category1_id),   category2_id = values(category2_id),   category3_id = values(cate
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 566 page no 107635 n bits 464 index `ind_pidoid` of table `cbu_cms`.`pool_offer` trx id 74247262209 lock_mode X
Record lock, heap no 30 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 8; hex 0000000000004acf; asc       J ;;
 1: len 8; hex 0000000a39f8a858; asc     9  X;;
 2: len 8; hex 0000000004086d36; asc       m6;;
 *** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 566 page no 107635 n bits 464 index `ind_pidoid` of table `cbu_cms`.`pool_offer` trx id 74247262209 lock_mode X waiting
Record lock, heap no 220 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 8; hex 0000000000004acf; asc       J ;;
 1: len 8; hex 0000000039f5e41c; asc     9   ;;
 2: len 8; hex 0000000003f74e7c; asc       N|;;

表結構

| pool_offer | CREATE TABLE `pool_offer` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '??',
  `gmt_create` datetime NOT NULL COMMENT '????',
  `gmt_modified` datetime NOT NULL COMMENT '????',
  `pool_id` bigint(20) unsigned DEFAULT NULL COMMENT '??ID',
  `offer_id` bigint(20) unsigned DEFAULT NULL COMMENT '??ID',
  `member_id` varchar(128) DEFAULT NULL COMMENT '??id',
  `status` varchar(64) DEFAULT NULL COMMENT '??',
  `del_operator` varchar(64) DEFAULT NULL COMMENT '?????',
  `creator` varchar(64) DEFAULT NULL COMMENT '?????',
  `modifier` varchar(64) DEFAULT NULL COMMENT '?????',
  `gmt_deleted` date DEFAULT NULL COMMENT '????',
  `enter_way` varchar(64) DEFAULT NULL COMMENT '??????',
  `sort` bigint(20) DEFAULT NULL COMMENT '??',
  `gmt_sort` datetime DEFAULT NULL COMMENT '????',
  `category_id` varchar(128) DEFAULT NULL COMMENT '????id',
  `category1_id` varchar(128) DEFAULT NULL COMMENT '????ID',
  `category2_id` varchar(128) DEFAULT NULL COMMENT '????ID',
  `category3_id` varchar(128) DEFAULT NULL COMMENT '????ID',
  `bu_id` varchar(128) DEFAULT NULL COMMENT 'BU ID',
  `expired_time` datetime DEFAULT NULL COMMENT '????',
  `offerstatus` varchar(30) DEFAULT 'published' COMMENT 'offer??(PUBLISHED???????offerdubbo??)',
  `cheat_flag` int(11) DEFAULT '0' COMMENT '????, 0???5????9???',
  `score` bigint(20) DEFAULT '0' COMMENT '?????????????????????*1000000??',
  `view_sort` bigint(20) DEFAULT NULL COMMENT 'offer??????',
  `conf_sort` bigint(20) DEFAULT NULL COMMENT '???????',
  `ds_tag` varchar(256) DEFAULT NULL COMMENT 'offer??????tag',
  `enroll_id` bigint(20) unsigned DEFAULT NULL COMMENT '??ID',
  `location` varchar(20000) DEFAULT NULL COMMENT '??????????????',
  `hpstatus` varchar(32) DEFAULT NULL COMMENT 'offer?????',
  PRIMARY KEY (`id`),
  UNIQUE KEY `ind_pidoid` (`pool_id`,`offer_id`),
  KEY `ind_memberid` (`member_id`),
  KEY `ind_gmtcreate` (`gmt_create`,`gmt_modified`),
  KEY `ind_gmtsort` (`gmt_sort`),
  KEY `idx_pool_offer_cat` (`pool_id`,`category_id`,`category1_id`,`category2_id`,`category3_id`,`member_id`,`offerstatus`),
  KEY `ind_offerid_status` (`offer_id`,`status`),
  KEY `ind_offer_pool_status` (`offer_id`,`pool_id`,`status`),
  KEY `ind_pidstatus` (`pool_id`,`status`,`ds_tag`(255)),
  KEY `ind_sort` (`pool_id`,`status`,`offerstatus`,`view_sort`,`score`)
) ENGINE=InnoDB AUTO_INCREMENT=67735804 DEFAULT CHARSET=utf8 COMMENT='???offer??' |

鎖超時

報錯
java.sql.SQLException: Lock wait timeout exceeded; try restarting transaction
select * from information_schema.innodb_trx\G 找到當前執行的所有事物
select * from information_schema.processlist where id =xxx 在processlist裡檢視這個id的執行緒
kill掉佔用鎖的執行緒
例子

記得以前，當出現：ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction，要解決是一件麻煩的事情；特別是當一個SQL執行完了，但未COMMIT，後面的SQL想要執行就是被鎖，超時結束，DBA光從資料庫無法著手找出源頭是哪個SQL鎖住了；有時候看看 show engine innodb status，並結合 show full processlist 能暫時解決問題，但一直不能精確定位。

在5.5中，information_schema 庫中增加了三個關於鎖的表（MEMORY引擎）：
- innodb_trx ## 當前執行的所有事務
- innodb_locks ## 當前出現的鎖
- innodb_lock_waits ## 鎖等待的對應關係
  看到這個就非常激動，這可是解決了一個大麻煩，先來看一下表結構：

[email protected]127.0.0.1 : 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]127.0.0.1 : 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]127.0.0.1 : 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)

下面我們來動手看看資料吧：

建立測試資料：

use test;
create table tx1
(id int primary key ,
c1 varchar(20),
c2 varchar(30))
engine=innodb default charset = utf8 ;

insert into tx1 values
(1,’aaaa’,'aaaaa2′),
(2,’bbbb’,'bbbbb2′),
(3,’cccc’,'ccccc2′);

commit;

產生事務

### Session1
start transaction;
update tx1 set c1=’heyf’,c2=’heyf’ where id = 3;

產生事務，在 innodb_trx 就有資料

[email protected]127.0.0.1 : information_schema 13:38:21> select * from innodb_trx \G
*************************** 1. row ***************************
                    trx_id: 3669D82
                 trx_state: RUNNING
               trx_started: 2010-12-24 13:38:06
     trx_requested_lock_id: NULL
          trx_wait_started: NULL
                trx_weight: 3
       trx_mysql_thread_id: 2344
                 trx_query: NULL
       trx_operation_state: NULL
         trx_tables_in_use: 0
         trx_tables_locked: 0
          trx_lock_structs: 2
     trx_lock_memory_bytes: 376
           trx_rows_locked: 1
         trx_rows_modified: 1
   trx_concurrency_tickets: 0
       trx_isolation_level: REPEATABLE READ
         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
1 row in set (0.00 sec)

### 由於沒有產生鎖等待，下面兩個表沒有資料
[email protected]127.0.0.1 : information_schema 13:38:31> select * from innodb_lock_waits \G
Empty set (0.00 sec)

[email protected]127.0.0.1 : information_schema 13:38:57> select * from innodb_locks \G
Empty set (0.00 sec)

產生鎖等待

#### session 2
start transaction;
update tx1 set c1=’heyfffff’,c2=’heyffffff’ where id =3 ;

[email protected] : information_schema 13:39:01> select * from innodb_trx \G
*************************** 1. row ***************************
                    trx_id: 3669D83   ##第2個事務
                 trx_state: LOCK WAIT   ## 處於等待狀態
               trx_started: 2010-12-24 13:40:07
     trx_requested_lock_id: 3669D83:49:3:4  ##請求的鎖ID
          trx_wait_started: 2010-12-24 13:40:07
                trx_weight: 2
       trx_mysql_thread_id: 2346       ##執行緒 ID
                 trx_query: update tx1 set c1=’heyfffff’,c2=’heyffffff’ where id =3
       trx_operation_state: starting index read
         trx_tables_in_use: 1      ##需要用到1個表
         trx_tables_locked: 1      ##有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: REPEATABLE READ
         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
*************************** 2. row ***************************
                    trx_id: 3669D82 ##第1個事務
                 trx_state: RUNNING
               trx_started: 2010-12-24 13:38:06
     trx_requested_lock_id: NULL
          trx_wait_started: NULL
                trx_weight: 3
       trx_mysql_thread_id: 2344
                 trx_query: NULL
       trx_operation_state: NULL
         trx_tables_in_use: 0
         trx_tables_locked: 0
          trx_lock_structs: 2
     trx_lock_memory_bytes: 376
           trx_rows_locked: 1
         trx_rows_modified: 1
   trx_concurrency_tickets: 0
       trx_isolation_level: REPEATABLE READ
         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
2 rows in set (0.00 sec)

[email protected] : information_schema 13:40:12> select * from innodb_locks \G
*************************** 1. row ***************************
    lock_id: 3669D83:49:3:4      ## 第2個事務需要的鎖
lock_trx_id: 3669D83
  lock_mode: X
  lock_type: RECORD
 lock_table: `test`.`tx1`
 lock_index: `PRIMARY`
 lock_space: 49
  lock_page: 3
   lock_rec: 4
  lock_data: 3
*************************** 2. row ***************************
    lock_id: 3669D82:49:3:4     ## 第1個事務需要的鎖
lock_trx_id: 3669D82
  lock_mode: X
  lock_type: RECORD
 lock_table: `test`.`tx1`
 lock_index: `PRIMARY`
 lock_space: 49
  lock_page: 3
   lock_rec: 4
  lock_data: 3
2 rows in set (0.00 sec)

[email protected] : information_schema 13:40:15> select * from innodb_lock_waits \G
*************************** 1. row ***************************
requesting_trx_id: 3669D83         ## 請求鎖的事務
requested_lock_id: 3669D83:49:3:4  ## 請求鎖的鎖ID
  blocking_trx_id: 3669D82         ## 擁有鎖的事務
 blocking_lock_id: 3669D82:49:3:4  ## 擁有鎖的鎖ID
1 row in set (0.00 sec)

參考:
MySQL 加鎖處理分析
 一個最不可思議的MySQL死鎖分析

mysql死鎖排查

死鎖 show engine innodb status;顯示引擎引數,查死鎖sql show engine innodb mutex; LATEST DETECTED DEADLOCK ------------------------ 2017-01-21

一次Mysql死鎖排查過程的全紀錄

前言之前接觸到的資料庫死鎖，都是批量更新時加鎖順序不一致而導致的死鎖，但是上週卻遇到了一個很難理解的死鎖。藉著這個機會又重新學習了一下mysql的死鎖知識以及常見的死鎖場景。在多方調研以及和同事們的討論下終於發現了這個死鎖問題的成因，收穫頗多。雖然是後端程式設計師，我們不需要

記錄一次Mysql死鎖排查過程

知識 body ext 兩個 next ron 討論不一致 test 背景以前接觸到的數據庫死鎖，都是批量更新時加鎖順序不一致而導致的死鎖，但是上周卻遇到了一個很難理解的死鎖。借著這個機會又重新學習了一下mysql的死鎖知識以及常見的死鎖場景。在多方調研以及和同事們的

Mysql死鎖如何排查：insert on duplicate死鎖一次排查分析過程

前言遇到Mysql死鎖問題，我們應該怎麼排查分析呢？之前線上出現一個insert on duplicate死鎖問題，本文將基於這個死鎖問題，分享排查分析過程，希望對大家有幫助。死鎖案發還原表結構： CREATE TABLE `song_rank` ( `id` int(11) NOT NULL AU

MySQL死鎖系列-線上死鎖問題排查思路

### 前言 MySQL 死鎖異常是我們經常會遇到的線上異常類別，一旦線上業務日間複雜，各種業務操作之間往往會產生鎖衝突，有些會導致死鎖異常。這種死鎖異常一般要在特定時間特定資料和特定業務操作才會復現，並且分析解決時還需要了解 MySQL 鎖衝突相關知識，所以一般遇到這些偶爾出現的死鎖異常，往往一時沒有頭緒

一次MySQL死鎖的排查記錄

前幾天線上收到一條告警郵件，生產環境MySQL操作發生了死鎖，郵件告警的提煉出來的SQL大致如下。 ```SQL update pe_order_product_info_test set end_time = '2021-04-30 23:59:59' where or

mysql-不恰當的update語句使用主鍵和索引導致mysql死鎖

行修改 sql錯誤狀態還要錯誤日誌示意圖 http 概率最小背景知識：MySQL有三種鎖的級別：頁級、表級、行級。 MyISAM和MEMORY存儲引擎采用的是表級鎖（table-level locking）；BDB存儲引擎采用的是頁面鎖（page-level l

死鎖排查的小竅門 --使用jdk自帶管理工具jstack

pre ble new deadlock 一段指令 tro bject print 本文版權歸遠方的風lyh和博客園共有，歡迎轉載，但須保留此段聲明，並給出原文鏈接，謝謝合作。開發時間久了，難免會寫出一些一些死鎖的代碼，自己明明調用該方法可該方法就是不執行、不進該

MySQL 死鎖與日誌二三事

mysql索引 open 靜態變量 ... 硬盤永久 state stack 應該最近線上 MySQL 接連發生了幾起數據異常，都是在淩晨爆發，由於業務場景屬於典型的數據倉庫型應用，白天壓力較小無法復現。甚至有些異常還比較詭異，最後 root cause 分析頗費周

0823關於整理MySQL死鎖

nod 淺析 sql html hub 關於理解 iyu www -- 更多的是需要理解 http://hedengcheng.com/?p=577 -- 何登成關於WHERE的提取http://www.cnblogs.com/metoy/p/5545580.html

MySQL死鎖

physical com ror 等待 mar 0 rows ans field mysql死鎖一、查看MySQL死鎖 MySQL數據庫會自己解決死鎖，kill掉一個session的事務，讓另外一個session的事務可以執行 SQL>SHOW ENGINE I

MySQL 死鎖

mil 等待 sql 超時至少 sof 時機 nod 系統　　死鎖指至少兩個事務請求占有對方的資源而造成相互等待的現象。數據庫系統可以通過檢測出死鎖的循環依賴即死鎖檢測或者查詢時間超時後放棄鎖請求即死鎖超時機制來解決死鎖問題。InnoDB處理死鎖方法：回滾持有最少行級排

sql server 死鎖排查

getdate rest spi 排它鎖 pro 版本 sql ack proxy 原文:sql server 死鎖排查記得以前客戶在使用軟件時，有偶發出現死鎖問題，因為發生的時間不確定，不好做問題的重現，當時解決問題有點棘手了。現總結下查看死

mysql 死鎖解決辦法

ESS .html blog proc 數據 lis 說明查詢 http 查詢表的時候，發現一圈圈轉啊轉，就是不出來數據，猜測表被鎖住解決辦法：　　mysql> show processlist ; 　　mysql> kill 4; 說明

基於innodb_print_all_deadlocks從errorlog中解析MySQL死鎖日誌

search 屬於賦值 lock png rim img 顯示 dea 本文是說明如何獲取死鎖日誌記錄的，不是說明如何解決死鎖問題的。 MySQL的死鎖可以通過show engine innodb status;來查看，但是show engine innodb s

MySQL-死鎖查詢

insert 再次通過 wid 從服務器階段 optimize 自動 connect 1、查詢是否鎖表 show OPEN TABLES where In_use > 0; 查詢到相對應的進程 === 然後 kill id 2、查詢進程 sh

MySQL死鎖簡單案例演示

MySQL死鎖簡單案例演示【存在疑問】請各位讀者對本篇文章採取疑問的態度。 1.環境 mysql 5.7 windows 2.示例1 mysql> CREATE TABLE t (i INT) ENGINE = InnoDB; Query

MySQL死鎖分析一例

Tomcat日誌報死鎖錯誤，show innodb status獲取死鎖資訊： ------------------------ LATEST DETECTED DEADLOCK ------------------------ 181107 9:30:46 *** (1) TRANSACTION:

【MYSQL死鎖問題】Deadlock found when trying to get lock;

問題：在多訪問的情況下，一個刪除計劃的操作會出現死鎖現象，報錯如下： ### Error updating database. Cause: com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock foun

mysql 死鎖簡單分析

-- hand ODB star 資源無法作用 dex size mysql都有什麽鎖 MySQL有三種鎖的級別：頁級、表級、行級，內存級（latch）。表級鎖：開銷小，加鎖快；不會出現死鎖；鎖定粒度大，發生鎖沖突的概率最高,並發度最低。行級鎖：開銷大，加鎖慢；會

mysql死鎖排查

死鎖

鎖超時

下面我們來動手看看資料吧：

產生事務，在 innodb_trx 就有資料

產生鎖等待

相關推薦