在生產環(huán)境下，有時公司客服反映網頁半天打不到，除了在瀏覽器按F12的Network響應來排查，確定web服務器無故障后。就需要檢查數據庫是否有出現阻塞

當時數據庫的生產環(huán)境中主表數據量超過2000w,子表數據量超過1億，且更新和新增頻繁。再加上做了同步鏡像，很消耗資源。

這時就要新建一個會話，大概需要了解以下幾點：

• 1.當前活動會話量有多少？
• 2.會話運行時間？
• 3.會話之間有沒有阻塞？
• 4.阻塞時間 ?

查詢阻塞的方法有很多。有sql 2000 的sp_lock, 有sql 2005及以上的dmv

一. 阻塞查詢 sp_lock

執(zhí)行 exec sp_lock  下面列下關鍵字段

spid 是指進程ID，這個過濾掉了系統進程，只展示了用戶進程spid>50。

dbid 指當前實例下的哪個數據庫 , 使用DB_NAME() 函數來標識數據庫

type 請求鎖住的模式

mode 鎖的請求狀態(tài)

• GRANT：已獲取鎖。
• CNVRT：鎖正在從另一種模式進行轉換，但是轉換被另一個持有鎖（模式相沖突）的進程阻塞。
• WAIT：鎖被另一個持有鎖（模式相沖突）的進程阻塞。

總結：當mode 不為GRANT狀態(tài)時， 需要了解當前鎖的模式，以及通過進程ID查找當前sql 語句 

例如當前進程ID是416，且mode狀態(tài)為WAIT 時，查看方式 DBCC INPUTBUFFER(416)

用sp_lock查詢顯示的信息量很少，也很難看出誰被誰阻塞。所以當數據庫版本為2005及以上時不建議使用。

 二.阻塞查詢  dm_tran_locks 

SELECT 
t1.resource_type,
t1.resource_database_id,
t1.resource_associated_entity_id,
t1.request_mode,
t1.request_session_id,
t2.blocking_session_id
FROM sys.dm_tran_locks as t1
INNER JOIN sys.dm_os_waiting_tasks as t2
ON t1.lock_owner_address = t2.resource_address;

上面查詢只顯示有阻塞的會話， 關注blocking_session_id 也就是被阻塞的會話ID，同樣使用DBCC INPUTBUFFER來查詢sql語句

三.阻塞查詢 sys.sysprocesses

SELECT 
 spid,
 kpid,
 blocked,
 waittime AS 'waitms', 
 lastwaittype, 
 DB_NAME(dbid)AS DB,  
 waitresource, 
 open_tran,
 hostname,[program_name],
 hostprocess,loginame,
 [status]
 FROM sys.sysprocesses WITH(NOLOCK) 
 WHERE    kpid>0  AND  [status]<>'sleeping'  AND spid>50
 AND spid<>@@SPID

sys.sysprocesses  能顯示會話進程有多少， 等待時間， open_tran有多少事務， 阻塞會話是多少. 整體內容更為詳細。
關鍵字段說明:

• spid 會話ID（進程ID），SQL內部對一個連接的編號，一般來講小于50
• kipid 線程ID
• blocked: 阻塞的進程ID， 值大于0表示阻塞, 值為本身進程ID表示io操作
• waittime:當前等待時間（以毫秒為單位）。
• open_tran: 進程的打開事務數
• hostname:建立連接的客戶端工作站的名稱
• program_name 應用程序的名稱。
• hostprocess 工作站進程 ID 號。
• loginame 登錄名。
• • [status]
  • running = 會話正在運行一個或多個批
  • background = 會話正在運行一個后臺任務，例如死鎖檢測
  • rollback = 會話具有正在處理的事務回滾
  • pending = 會話正在等待工作線程變?yōu)榭捎?/li>
  • runnable = 會話中的任務在等待,由scheduler來運行的可執(zhí)行隊列中。(重要)
  • spinloop = 會話中的任務正在等待調節(jié)鎖變?yōu)榭捎谩?/li>
  • suspended = 會話正在等待事件（如 I/O）完成。(重要)
  • sleeping = 連接空閑
  • wait resource 格式為 fileid:pagenumber:rid 如(5:1:8235440)
  • kpid=0, waittime=0 空閑連接
  • kpid>0, waittime=0 運行狀態(tài)
  • kpid>0, waittime>0 需要等待某個資源，才能繼續(xù)執(zhí)行,一般會是suspended（等待io）
  • kpid=0, waittime=0 但它還是阻塞的源頭，查看open_tran>0 事務沒有及時提交。

如果blocked>0，但waittime時間很短，說明阻塞時間不長，不嚴重
如果status 上有好幾個runnable狀態(tài)任務，需要認真對待。 cpu負荷過重沒有及時處理用戶的并發(fā)請求

到此這篇關于sql server查詢語句阻塞優(yōu)化性能的文章就介紹到這了。希望對大家的學習有所幫助，也希望大家多多支持腳本之家。

最新評論