mysql怎么檢測死瑣 MySQL檢測死鎖
mysql在哪個文件查看鎖死表信息?謝謝,或者如何查看
以下五種方法可以快速定位全局鎖的位置，僅供參考。
創(chuàng)新互聯(lián)10多年成都定制網(wǎng)站服務;為您提供網(wǎng)站建設,網(wǎng)站制作,網(wǎng)頁設計及高端網(wǎng)站定制服務,成都定制網(wǎng)站及推廣,對OPP膠袋等多個方面擁有豐富的網(wǎng)站運維經(jīng)驗的網(wǎng)站建設公司。
方法1：利用 metadata_locks 視圖
此方法僅適用于 MySQL 5.7 以上版本，該版本 performance_schema 新增了 metadata_locks，如果上鎖前啟用了元數(shù)據(jù)鎖的探針（默認是未啟用的），可以比較容易的定位全局鎖會話。
方法2：利用 events_statements_history 視圖此方法適用于 MySQL 5.6 以上版本，啟用 performance_schema.eventsstatements_history（5.6 默認未啟用，5.7 默認啟用），該表會 SQL 歷史記錄執(zhí)行，如果請求太多，會自動清理早期的信息，有可能將上鎖會話的信息清理掉。
方法3：利用 gdb 工具如果上述兩種都用不了或者沒來得及啟用，可以嘗試第三種方法。利用 gdb 找到所有線程信息，查看每個線程中持有全局鎖對象，輸出對應的會話 ID，為了便于快速定位，我寫成了腳本形式。也可以使用 gdb 交互模式，但 attach mysql 進程后 mysql 會完全 hang 住，讀請求也會受到影響，不建議使用交互模式。
方法4：show processlist
如果備份程序使用的特定用戶執(zhí)行備份，如果是 root 用戶備份，那 time 值越大的是持鎖會話的概率越大，如果業(yè)務也用 root 訪問，重點是 state 和 info 為空的，這里有個小技巧可以快速篩選，篩選后嘗試 kill 對應 ID，再觀察是否還有 wait global read lock 狀態(tài)的會話。
方法5：重啟試試！
如何查mysql死鎖進程
查詢死鎖進程
采用如下存儲過程來查詢數(shù)據(jù)中當前造成死鎖的進程。
drop procedure sp_who_lock
go
CREATE procedure sp_who_lock
as
begin
declare @spid int
declare @blk int
declare @count int
declare @index int
declare @lock tinyint
set @lock=0
create table #temp_who_lock
(
id int identity(1,1),
spid int,
blk int
)
if @@error0 return @@error
insert into #temp_who_lock(spid,blk)
select 0 ,blocked
from (select * from master..sysprocesses where blocked0)a
where not exists(select * from master..sysprocesses where a.blocked =spid and blocked0)
union select spid,blocked from master..sysprocesses where blocked0
if @@error0 return @@error
select @count=count(*),@index=1 from #temp_who_lock
if @@error0 return @@error
if @count=0
begin
select '沒有阻塞和死鎖信息'
return 0
end
while @indexA href="mailto:=@count"=@count
begin
if exists(select 1 from #temp_who_lock a where id@index and exists(select 1 from #temp_who_lock where idA href="mailto:=@index"=@index and a.blk=spid))
begin
set @lock=1
select @spid=spid,@blk=blk from #temp_who_lock where id=@index
select '引起數(shù)據(jù)庫死鎖的是: '+ CAST(@spid AS VARCHAR(10)) + '進程號,其執(zhí)行的SQL語法如下'
select @spid, @blk
dbcc inputbuffer(@spid)
dbcc inputbuffer(@blk)
end
set @index=@index+1
end
if @lock=0
begin
set @index=1
while @indexA href="mailto:=@count"=@count
begin
select @spid=spid,@blk=blk from #temp_who_lock where id=@index
if @spid=0
select '引起阻塞的是:'+cast(@blk as varchar(10))+ '進程號,其執(zhí)行的SQL語法如下'
else
select '進程號SPID：'+ CAST(@spid AS VARCHAR(10))+ '被' + '進程號SPID：'+ CAST(@blk AS VARCHAR(10)) +'阻塞,其當前進程執(zhí)行的SQL語法如下'
dbcc inputbuffer(@spid)
dbcc inputbuffer(@blk)
set @index=@index+1
end
end
drop table #temp_who_lock
return 0
end
GO
--執(zhí)行該存儲過程
exec sp_who_lock
補充：
一、產(chǎn)生死鎖的原因
在SQL Server中，阻塞更多的是產(chǎn)生于實現(xiàn)并發(fā)之間的隔離性。為了使得并發(fā)連接所做的操作之間的影響到達某一期望值而對資源人為的進行加鎖(鎖本質(zhì)其實可以看作是一個標志位)。當一個連接對特定的資源進行操作時，另一個連接同時對同樣的資源進行操作就會被阻塞，阻塞是死鎖產(chǎn)生的必要條件。
二、如何避免死鎖
1.使用事務時，盡量縮短事務的邏輯處理過程，及早提交或回滾事務；
2.設置死鎖超時參數(shù)為合理范圍，如：3分鐘-10分種；超過時間，自動放棄本次操作，避免進程懸掛；
3.優(yōu)化程序，檢查并避免死鎖現(xiàn)象出現(xiàn)；
4.對所有的腳本和SP都要仔細測試，在正是版本之前；
5.所有的SP都要有錯誤處理（通過@error）；
6.一般不要修改SQL SERVER事務的默認級別。不推薦強行加鎖。
三、處理死鎖
1、最簡單的處理死鎖的方法就是重啟服務。
2、根據(jù)指定的死鎖進程ID進行處理
根據(jù)第二步查詢到的死鎖進行，大致分析造成死鎖的原因，并通過如下語句釋放該死鎖進程
kill pid --pid為查詢出來的死鎖進程號
3、通過存儲過程殺掉某個庫下面的所有死鎖進程和鎖
if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[sp_killspid]') and OBJECTPROPERTY(id, N'IsProcedure') = 1)
drop procedure [dbo].[sp_killspid]
GO
create proc sp_killspid
@dbname varchar(200) --要關閉進程的數(shù)據(jù)庫名
as
declare @sql nvarchar(500)
declare @spid nvarchar(20)
declare #tb cursor for
select spid=cast(spid as varchar(20)) from master..sysprocesses where dbid=db_id(@dbname)
open #tb
fetch next from #tb into @spid
while @@fetch_status=0
begin
exec('kill '+@spid)
fetch next from #tb into @spid
end
close #tb
deallocate #tb
go
--使用方法，“db_name”為處理的數(shù)據(jù)庫名稱
exec sp_killspid 'db_name'
mysql 查看死鎖
第一步，查出已鎖的進程
查看正在鎖的事務
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;
``
查看等待鎖的事務
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;
``
INNODB_TRX表主要是包含了正在InnoDB引擎中執(zhí)行的所有事務的信息，包括waiting for a lock和running的事務
select * from information_schema.innodb_trx
``
第二步，kill進程
show engin innodb status; //最后一次死鎖信息及sql
show open tables where in_use 0 //查看鎖表
查詢mysql 哪些表正在被鎖狀態(tài)
1.查看表是否被鎖：
（1）直接在mysql命令行執(zhí)行:showengineinnodbstatus\G。
（2）查看造成死鎖的sql語句，分析索引情況，然后優(yōu)化sql。
（3）然后showprocesslist,查看造成死鎖占用時間長的sql語句。
（4）showstatuslike‘%lock%。
2.查看表被鎖狀態(tài)和結束死鎖步驟：
（1）查看表被鎖狀態(tài)：showOPENTABLESwhereIn_use0;這個語句記錄當前鎖表狀態(tài)。
（2）查詢進程：showprocesslist查詢表被鎖進程；查詢到相應進程killid。
（3）分析鎖表的SQL：分析相應SQL，給表加索引，常用字段加索引，表關聯(lián)字段加索引。
（4）查看正在鎖的事物：SELECT*FROMINFORMATION_SCHEMA.INNODB_LOCKS。
（5）查看等待鎖的事物：SELECT*FROMINFORMATION_SCHEMA.INNODB_LOCK_WAITS。
擴展資料
MySQL鎖定狀態(tài)查看命令：
Checkingtable：正在檢查數(shù)據(jù)表（這是自動的）。
Closingtables：正在將表中修改的數(shù)據(jù)刷新到磁盤中，同時正在關閉已經(jīng)用完的表。這是一個很快的操作，如果不是這樣的話，就應該確認磁盤空間是否已經(jīng)滿了或者磁盤是否正處于重負中。
ConnectOut：復制從服務器正在連接主服務器。
Copyingtotmptableondisk：由于臨時結果集大于tmp_table_size，正在將臨時表從內(nèi)存存儲轉為磁盤存儲以此節(jié)省內(nèi)存。
Creatingtmptable：正在創(chuàng)建臨時表以存放部分查詢結果。
deletingfrommaintable：服務器正在執(zhí)行多表刪除中的第一部分，剛刪除第一個表。
deletingfromreferencetables：服務器正在執(zhí)行多表刪除中的第二部分，正在刪除其他表的記錄。
Flushingtables：正在執(zhí)行FLUSHTABLES，等待其他線程關閉數(shù)據(jù)表。
Killed：發(fā)送了一個kill請求給某線程，那么這個線程將會檢查kill標志位，同時會放棄下一個kill請求。MySQL會在每次的主循環(huán)中檢查kill標志位，不過有些情況下該線程可能會過一小段才能死掉。如果該線程程被其他線程鎖住了，那么kill請求會在鎖釋放時馬上生效。
Locked：被其他查詢鎖住了。
Sendingdata：正在處理SELECT查詢的記錄，同時正在把結果發(fā)送給客戶端。
Sortingforgroup：正在為GROUPBY做排序。
Sortingfororder：正在為ORDERBY做排序。
Openingtables：這個過程應該會很快，除非受到其他因素的干擾。例如，在執(zhí)ALTERTABLE或LOCKTABLE語句行完以前，數(shù)據(jù)表無法被其他線程打開。正嘗試打開一個表。
Removingduplicates：正在執(zhí)行一個SELECTDISTINCT方式的查詢，但是MySQL無法在前一個階段優(yōu)化掉那些重復的記錄。因此，MySQL需要再次去掉重復的記錄，然后再把結果發(fā)送給客戶端。
Reopentable：獲得了對一個表的鎖，但是必須在表結構修改之后才能獲得這個鎖。已經(jīng)釋放鎖，關閉數(shù)據(jù)表，正嘗試重新打開數(shù)據(jù)表。
Repairbysorting：修復指令正在排序以創(chuàng)建索引。
Repairwithkeycache：修復指令正在利用索引緩存一個一個地創(chuàng)建新索引。它會比Repairbysorting慢些。
Searchingrowsforupdate：正在講符合條件的記錄找出來以備更新。它必須在UPDATE要修改相關的記錄之前就完成了。
Sleeping：正在等待客戶端發(fā)送新請求。
Systemlock：正在等待取得一個外部的系統(tǒng)鎖。如果當前沒有運行多個mysqld服務器同時請求同一個表，那么可以通過增加--skip-external-locking參數(shù)來禁止外部系統(tǒng)鎖。
Upgradinglock：INSERTDELAYED正在嘗試取得一個鎖表以插入新記錄。
Updating：正在搜索匹配的記錄，并且修改它們。
UserLock：正在等待GET_LOCK()。
Waitingfortables：該線程得到通知，數(shù)據(jù)表結構已經(jīng)被修改了，需要重新打開數(shù)據(jù)表以取得新的結構。然后，為了能的重新打開數(shù)據(jù)表，必須等到所有其他線程關閉這個表。
waitingforhandlerinsert：INSERTDELAYED已經(jīng)處理完了所有待處理的插入操作，正在等待新的請求。
詳解MySQL（InnoDB）如何處理死鎖
鎖是需要事務結束后才釋放的。
一個是 MVCC，一個是兩階段鎖協(xié)議。
為什么要并發(fā)控制呢？是因為多個用戶同時操作 MySQL 的時候，為了提高并發(fā)性能并且要求如同多個用戶的請求過來之后如同串行執(zhí)行的一樣（為了解決臟讀、不可重復讀、幻讀）
官方定義：
兩階段鎖協(xié)議是指所有事務必須分兩個階段對數(shù)據(jù)加鎖和解鎖，在對任何數(shù)據(jù)進行讀、寫操作之前，事務首先要獲得對該數(shù)據(jù)的封鎖；在釋放一個封鎖之后，事務不再申請和獲得任何其他封鎖。
對應到 MySQL 上分為兩個階段：
但是兩階段鎖協(xié)議不要求事務必須一次將所有需要使用的數(shù)據(jù)加鎖（innodb在需要的索引列數(shù)據(jù)才鎖行），并且在加鎖階段沒有順序要求，所以這種并發(fā)控制方式會形成死鎖。
MySQL有兩種死鎖處理方式：
死鎖檢測 （默認開啟）
死鎖檢測的原理是構建一個以事務為頂點、鎖為邊的有向圖，判斷有向圖是否存在環(huán)，存在即有死鎖。
回滾
檢測到死鎖之后，選擇插入更新或者刪除的行數(shù)最少的事務回滾，基于 INFORMATION_SCHEMA.INNODB_TRX 表中的 trx_weight 字段來判斷。
收集死鎖信息：
減少死鎖：
死鎖解決：
網(wǎng)頁標題：mysql怎么檢測死瑣 MySQL檢測死鎖
網(wǎng)站地址：http://m.jiaotiyi.com/article/hpsiso.html