SQL Server Key Hash Value 深度解析 (下)：鎖定資源的核心機制、版本差異與 %%lockres%%

承上篇探討，確認 Key Hash Value (Lock Hash) 並非用於索引 Seek 定位，而是鎖管理子系統識別資源的雜湊值。本文深入解析鎖資源類型、Key Hash 產生演算法、SQL 2005/2012 版本差異與 %%lockres%% 虛擬欄位實戰。

鎖資源類型與 Key Hash 角色

KEY 鎖 依賴 Key Hash Value (6 Bytes) 代表索引鍵，避免在鎖管理結構中儲存完整鍵值 (最長 900 Bytes)，節省記憶體並加速雜湊表查找。

為何需要 Key Hash？C# lock 類比

// C# 鎖模式
lock (syncObject) { /* critical section */ }
// syncObject 相當於 Key Hash Value：同一資源的所有執行緒共用同一雜湊值作為同步物件

• 索引鍵長達 900 Bytes，若直接作為鎖物件，記憶體消耗極大、比較緩慢。
• SQL 7.0 (1996) 引入雜湊演算法，將任意長度鍵值映射為 6 Bytes Lock Hash，作為鎖管理雜湊表的 Key。
• 參考文獻：Improvement in minimizing lockhash key collisions in SQL Server 2008 R2 and its impact on concurrency。

版本差異：SQL 2005 vs 2012

• SQL 2005：DBCC PAGE 輸出的資料頁記錄中 不顯示 KeyHashValue (除非開啟追蹤旗標)。僅能透過 %%lockres%% 查詢。
• SQL 2012+：DBCC PAGE 直接顯示每筆記錄的 KeyHashValue = (xxxxxxxxxxxx)，且 %%lockres%% 仍可用。
• 推測 SQL 2008 起開始內建顯示，但無 2008 環境驗證。

實戰：查看 Key Hash Value

-- 1. 虛擬欄位 %%lockres%% (所有版本通用)
SELECT %%lockres%% AS LockResource, *
FROM dbo.MyTable
WHERE ID = 123;
-- 結果範例：(8194443284a0)  -- 6 Bytes 十六進位

-- 2. DBCC PAGE 直接觀察 (SQL 2012+)
DBCC TRACEON(3604, -1);
GO
DBCC PAGE('MyDB', 1, 126, 3); -- File 1, Page 126, Print Option 3 (詳細記錄)
GO
-- 輸出片段：
-- Slot 0 Offset 0x0 Length 0 ...
-- KeyHashValue = (8194443284a0)  <-- 直接可見

鎖衝突與效能影響

• Lock Hash Collision：不同鍵值產生相同 6 Bytes 雜湊值 (極低機率)，導致誤判為鎖衝突，引發不必要的阻塞。
• SQL 2008 R2 改進雜湊演算法降低碰撞率，顯著提升高併發下鎖效能。
• DBA 可監控 sys.dm_os_wait_stats 中 LCK_M_* 等待，若異常偏高且無明顯邏輯衝突，可懷疑碰撞 (極罕見)。

總結

1. Key Hash Value = Lock Hash，用於鎖管理子系統識別索引鍵資源。
2. 6 Bytes 固定長度，源自 900 Bytes 鍵值上限的效能考量。
3. SQL 2012+ 可直接用 DBCC PAGE 或 %%lockres%% 觀察，利於鎖問題診斷。