如何查看MySQL數(shù)據(jù)庫的死鎖信息

如何查看MySQL數(shù)據(jù)庫的死鎖日志

創(chuàng)新互聯(lián)公司是一家專業(yè)提供濰坊企業(yè)網(wǎng)站建設(shè),專注與網(wǎng)站設(shè)計制作、網(wǎng)站建設(shè)、H5建站、小程序制作等業(yè)務(wù)。10年已為濰坊眾多企業(yè)、政府機構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)絡(luò)公司優(yōu)惠進(jìn)行中。

1. 使用終端或命令提示符登錄到MySQL，輸入命令：mysql -h xxxx.xxx.xxx -P 3306 -u username -p

解釋：xxxx.xxx.xxx是數(shù)據(jù)庫IP地址，username是數(shù)據(jù)庫用戶名，輸入命令后，會讓你輸入username對應(yīng)的密碼，就可以登錄了

2. 如何查看MySQL數(shù)據(jù)庫的死鎖信息

在MySQL客戶端下輸入命令：

show engine innodb status \G;

3. 如何定位MySQL數(shù)據(jù)庫的死鎖信息

在打印出來的信息中找到“LATEST DETECTED DEADLOCK”一節(jié)內(nèi)容，看圖中紅線

能否將死鎖信息保存到日志中

在之前的版本，要查看死鎖，你要show engine innodb status\G;

在MySQL5.6版本，在my點吸煙 f配置文件里，加入

innodb_print_all_deadlocks = 1

就可以把死鎖信息打印到錯誤日志里。

下面是一個死鎖演示：。。。。略

# more mysql5_6.err

121012 10:33:40 [Note]

/usr/local/mysql/bin/mysqld: ready for connections.

Version:

'5.6.6-m9-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Server

（GPL）

InnoDB: transactions deadlock detected, dumping detailed

information.

121012 10:35:07

*** （1） TRANSACTION:

TRANSACTION 304904, ACTIVE 49 sec starting index read

mysql tables in use

1, locked 1

LOCK WAIT 3 lock struct（s）， heap size 320, 2 row lock（s），

undo log entries 1

MySQL thread id 1, OS thread handle 0x9106cb90, query

id 13 localhost root updating

update t2 set name='cc1' where id=3

*** （1） WAITING FOR THIS LOCK TO BE GRANTED:

RECORD LOCKS space id 1201

page no 3 n bits 80 index `PRIMARY` of table `test`.`t2` trx id 304904 lock_mode

X locks rec but not gap waiting

Record lock, heap no 12 PHYSICAL RECORD:

n_fields 4; compact format; info bits 0

0: len 4; hex 80000003; asc

1: len 6; hex 00000004a709; asc

2: len 7; hex

09000002f401ca; asc

3: len 2; hex 6363; asc cc

*** （2）

TRANSACTION:

TRANSACTION 304905, ACTIVE 15 sec starting index read

mysql tables in use 1, locked 1

3 lock struct（s）， heap size 320, 2 row

lock（s）， undo log entries 1

MySQL thread id 2, OS thread handle

0x9103bb90, query id 14 localhost root updating

update t2 set name='bb1'

where id=2

*** （2） HOLDS THE LOCK（S）：

RECORD LOCKS space id 1201

page no 3 n bits 80 index `PRIMARY` of table `test`.`t2` trx id 304905 lock_mode

X locks rec but not gap

Record lock, heap no 12 PHYSICAL RECORD: n_fields

4; compact format; info bits 0

0: len 4; hex 80000003; asc

1: len 6; hex 00000004a709; asc

2: len 7; hex 09000002f401ca;

asc

3: len 2; hex 6363; asc cc

*** （2） WAITING FOR

THIS LOCK TO BE GRANTED:

RECORD LOCKS space id 1201 page no 3 n bits 80

index `PRIMARY` of table `test`.`t2` trx id 304905 lock_mode X locks rec but not

gap waiting

Record lock, heap no 11 PHYSICAL RECORD: n_fields 4; compact

format; info bits 0

0: len 4; hex 80000002; asc

1: len 6;

hex 00000004a708; asc

2: len 7; hex 08000002522e5c; asc

R.\

3: len 2; hex 6262; asc bb

*** WE ROLL BACK TRANSACTION

（2）

參見手冊：

解決一次mysql死鎖問題

多線程開啟事務(wù)處理。每個事務(wù)有多個update操作和一個insert操作（都在同一張表）。

默認(rèn)隔離級別：Repeatable Read

只有hotel_id=2和hotel_id=11111的數(shù)據(jù)

邏輯刪除原有數(shù)據(jù)

插入新的數(shù)據(jù)

根據(jù)現(xiàn)有數(shù)據(jù)情況，update的時候沒有數(shù)據(jù)被更新

報了非常多一樣的錯

發(fā)現(xiàn)居然有死鎖。

根據(jù)常識考慮，我每個線程（事務(wù)）更新的數(shù)據(jù)都不沖突，為什么會產(chǎn)生死鎖？

帶著這個問題，打印mysql最近一次的死鎖信息

show engine innodb status

顯示如下

發(fā)現(xiàn)事務(wù)1在等待一個鎖

事務(wù)2也在等待一個鎖

而且事物2持有了事物1需要的鎖

關(guān)于鎖的描述，出現(xiàn)了 lock_mode ， gap before rec ， insert intention 等字眼，看不懂說明了什么？說明我關(guān)于mysql的鎖相關(guān)的知識儲備還不夠。那就開始調(diào)查mysql的鎖相關(guān)知識。

通過搜索引擎，

鎖的持有兼容程度如下表

那么再回到死鎖日志，可以知道 :

事務(wù)1正在獲取插入意向鎖

事務(wù)2正在獲取插入意向鎖，持有排他gap鎖

再看我們上面的鎖兼容表格，可以知道， gap lock和insert intention lock是不兼容的

那么就可以推斷出： 事務(wù)1持有g(shù)ap lock，等待事務(wù)2的insert intention lock釋放；事務(wù)2持有g(shù)ap lock，等待事務(wù)1的insert intention lock釋放，從而導(dǎo)致死鎖。

那么新的問題就來了，事務(wù)1的intention lock 為什么會和事務(wù)2的gap lock 有交集，或者說，事務(wù)1要插入的數(shù)據(jù)的位置為什么會被事務(wù)2給鎖住？

讓我回顧一下gap lock的定義：

間隙鎖，鎖定一個范圍，但不包括記錄本身。GAP鎖的目的，是為了防止同一事務(wù)的兩次當(dāng)前讀，出現(xiàn)幻讀的情況

那為什么是gap lock，gap lock到底是基于什么邏輯鎖的記錄？發(fā)現(xiàn)自己相關(guān)的知識儲備還不夠。那就開始調(diào)查。

調(diào)查后發(fā)現(xiàn)，當(dāng)當(dāng)前索引是一個 普通索引 的時候，會加一個gap lock來防止幻讀， 此gap lock 會鎖住一個左開右閉的區(qū)間。 假設(shè)索引為xx_idx（xx_id），數(shù)據(jù)分布為1,4,6,8,12，當(dāng)更新xx_id=9的時候，這個時候gap lock的鎖定記錄區(qū)間就是(8，12]，也就是鎖住了xxid in (9,10,11,12)的數(shù)據(jù)，當(dāng)有其他事務(wù)要插入xxid in (9,10,11,12)的數(shù)據(jù)時，就會處于等待獲取鎖的狀態(tài)。

ps：當(dāng)前索引不是普通索引，而且是唯一索引等其他情況，請參考下面資料

MySQL 加鎖處理分析

回到我自己的案例中，重新屢一下事務(wù)1的執(zhí)行過程：

因為普通索引

KEY hotel_date_idx ( hotel_id , rate_date )

的關(guān)系 這段sql會獲取一個gap lock，范圍(2,11111]

這段sql會獲取一個insert intention lock （waiting）

再看事務(wù)2的執(zhí)行過程

因為普通索引

KEY hotel_date_idx ( hotel_id , rate_date )

的關(guān)系 這段sql也會獲取一個gap lock，范圍也是(2,11111]（根據(jù)前面的知識，gap lock之間會互相兼容，可以一起持有鎖的）

這段sql也會獲取一個insert intention lock （waiting）

看到這里，基本也就破案了。因為普通索引的關(guān)系，事務(wù)1和事務(wù)2的gap lock的覆蓋范圍太廣，導(dǎo)致其他事務(wù)無法插入數(shù)據(jù)。

重新梳理一下：

所以從結(jié)果來看，一堆事務(wù)被回滾，只有10007數(shù)據(jù)被更新成功

gap lock 導(dǎo)致了并發(fā)處理的死鎖

在mysql默認(rèn)的事務(wù)隔離級別（repeatable read）下，無法避免這種情況。只能把并發(fā)處理改成同步處理。或者從業(yè)務(wù)層面做處理。

共享鎖、排他鎖、意向共享、意向排他

record lock、gap lock、next key lock、insert intention lock

show engine innodb status

網(wǎng)站題目：mysql死鎖怎么打印 mysql解決死鎖的4種基本方法
文章分享：http://chinadenli.net/article6/ddgeoog.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供App開發(fā)、做網(wǎng)站、標(biāo)簽優(yōu)化、搜索引擎優(yōu)化、商城網(wǎng)站、面包屑導(dǎo)航

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)