在生產環境下，有時公司客服反映網頁半天打不到，除了在瀏覽器按F12的Network響應來排查，確定web服務器無故障後。就需要檢查數據庫是否有出現阻塞
當時數據庫的生產環境中主表數據量超過2000w,子表數據量超過1億，且更新和新增頻繁。再加上做了同步鏡像，很消耗資源。
這時就要新建一個會話，大概需要了解以下幾點：
1.當前活動會話量有多少？
2.會話運行時間？
3.會話之間有沒有阻塞？
4.阻塞時間 ?
查詢阻塞的方法有很多。有sql 2000 的sp_lock, 有sql 2005及以上的dmv
一. 阻塞查詢 sp_lock
執行 exec sp_lock 下面列下關鍵字段
spid 是指進程ID，這個過濾掉了系統進程，只展示了用戶進程spid>50。
dbid 指當前實例下的哪個數據庫 , 使用DB_NAME() 函數來標識數據庫
type 請求鎖住的模式
mode 鎖的請求狀態
GRANT：已獲取鎖。
CNVRT：鎖正在從另一種模式進行轉換，但是轉換被另一個持有鎖（模式相沖突）的進程阻塞。
WAIT：鎖被另一個持有鎖（模式相沖突）的進程阻塞。
總結：當mode 不爲GRANT狀態時， 需要了解當前鎖的模式，以及通過進程ID查找當前sql 語句
例如當前進程ID是416，且mode狀態爲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 = 會話正在等待工作線程變爲可用
runnable = 會話中的任務在等待,由scheduler來運行的可執行隊列中。(重要)
spinloop = 會話中的任務正在等待調節鎖變爲可用。
suspended = 會話正在等待事件（如 I/O）完成。(重要)
sleeping = 連接空閒
wait resource 格式爲 fileid:pagenumber:rid 如(5:1:8235440)
kpid=0, waittime=0 空閒連接
kpid>0, waittime=0 運行狀態
kpid>0, waittime>0 需要等待某個資源，才能繼續執行,一般會是suspended（等待io）
kpid=0, waittime=0 但它還是阻塞的源頭，查看open_tran>0 事務沒有及時提交。
如果blocked>0，但waittime時間很短，說明阻塞時間不長，不嚴重
如果status 上有好幾個runnable狀態任務，需要認真對待。 cpu負荷過重沒有及時處理用戶的併發請求