鎖定是 SQL Server 資料庫引擎用來同步多個使用者同時對同一個資料塊的訪問的一種機制。

1. 基本概念
2. 利用SQL Server Profiler觀察鎖
3. 死鎖產生的原因及避免
4. 總結

基本概念

資料庫引擎隔離級別

鎖粒度

鎖型別

利用SQL Server Profiler觀察鎖

1. 準備資料10條資料

create table DataTable(Id int identity(1,1), [Name] varchar(50), [Address] varchar(200), CreateTime datetime2)
    
insert into DataTable
select 'Wilson','廣東省廣州市',GETDATE() union all
select 'Alice','北京市朝陽區',GETDATE() union all
select 'Miksovsky','吉林省松原市',GETDATE() union all
select 'Hines','甘肅省蘭州市',GETDATE() union all
select 'Kane','遼寧省瀋陽市',GETDATE() union all
select 'Gode','湖北省荊州市',GETDATE() union all
select 'Chen','湖南省岳陽市',GETDATE() union all
select 'Trenary','福建省廈門市',GETDATE() union all
select 'Achong','廣西省玉林市',GETDATE() union all
select 'Nixon','江西省景德鎮',GETDATE() 

2. 開啟SQL Server Profiler選中鎖事件，勾選type和mode，建議取消不需要觀察的列，然後用列篩選器過濾要觀察的DB

3. 查詢資料

 可以看到在頁面級別加上意向共享鎖，因為我們資料只有一頁

4. 更新一條資料

1. 表上加上意向排它鎖（IX），可以用select OBJECT_NAME(581577110) 檢視objectid代表的東西

2. 頁級別加上意向更新鎖（IU），告訴SQL Server引擎這裡有更新鎖

3. 獲取第一行的更新鎖（U），這裡條件匹配

4. 頁級別升級為意向排他鎖（IX）, 告訴SQL Server引擎這裡有排他鎖

5. 第一個行更新鎖 升級為排它鎖（X）

6. 釋放鎖

7. 隨條掃描後面的記錄，只是條件不符合，也就不會升級鎖級別

可以看到是全表掃描，因為沒聚集索引（堆表），我們也沒做一個主鍵，下面將Id新增主鍵然後再更新試試

alter table DataTable add constraint PK_DataTable primary key(Id asc)

 可以看出，直接在表，頁級別加上意向排它鎖（IX），然後在鍵上加上排它鎖（X）

因為這裡我們用主鍵更新，而且SQL Server主鍵預設是聚集索引，如果指定是非聚集索引主鍵，這裡也會經歷更新鎖 到 排他鎖，有興趣的可以自行驗證

5. 刪除一條資料

 這次我們沒用主鍵刪除，過程和更新的第一種情況差不多，就不列了。

因為加了聚集索引，索引定位器執行聚集索引Key的hash，要驗證是否那條記錄，可以在刪除前加上%%lockres%%去查

死鎖產生的原因及避免

死鎖產生的原因

微軟文件是這樣說

在兩個或多個任務中，如果每個任務鎖定了其他任務試圖鎖定的資源，此時會造成這些任務永久阻塞，從而出現死鎖

我理解就是有2個事務迴圈依賴對方的資源導致產生死鎖。

例如

1. 事務A 獲取 Row1 資源

2. 事務B 獲取 Row2 資源

3. 事務A獲取Row2資源，由於這時Row2是被事務B佔有，所以必須等事務B完成

4. 事務B獲取Row1資源，由於這時Row1是被事務A佔有，所以必須等事務A完成

SQL Server處理死鎖策略

1. 定期檢查陷入死鎖的任務

2. 若檢查到迴圈依賴

3. 選擇其中一個作為犧牲品，然後終止事務，然另外一個得以完成

模擬死鎖

分別在兩個不同的會話執行下面語句

begin tran;

update DataTable set Address = '上海市' where Id = 2;
--延遲5秒執行
WAITFOR DELAY '00:00:05';
update DataTable set Address = '上海市' where Id = 3;

commit;

begin tran;

update DataTable set Address = '上海市' where Id = 3;
--延遲5秒執行
WAITFOR DELAY '00:00:05';
update DataTable set Address = '上海市' where Id = 2;

commit;

執行一段時間，其中一個會出現下面錯誤

SQL Server Profiler 捕獲死鎖分析

開啟Locks事件的死鎖圖形

 重新執行上面語句，模擬死鎖，Profiler捕獲到死鎖

可以看出

1. 程序56 請求的Key 的排它鎖  被程序 54 佔有

2. 程序54 請求的Key 的排他鎖 被程序 56 佔有

3. 形成了迴圈依賴

我們這裡的Sql比較簡單，而且沒有用引數化執行，所以我們指定是哪一行被鎖，線上的通常不能直接看到哪一行被鎖

我們可以通過xml檢視等待的資源，在xml裡面有process-list 下面有多個process，process節點上面有個waitresource屬性，這個指出每個程序等待的資源

鎖型別：db_id : hobt_id : (hashvalue)

KEY: 6:72057594043760640 (61a06abd401c)

通過%%lockres%% 查到被鎖資源

select %%lockres%%,* from DataTable where %%lockres%% = '(98ec012aa510)'

鎖型別不一樣，得到的會不一樣，根據各自的格式用db_name / object_name  / dbcc去查到當前被鎖的資源，有時候需要利用DBCC查詢Page儲存頁面，可以參考上一篇文章【SQL SERVER】資料內部儲存結構簡單探索

避免死鎖

首先需要說明死鎖不能完全避免，但遵守特定的編碼慣例可以將發生死鎖的機會降至最低

1. 按同一順序訪問物件，一個獲取鎖，另外一個就必須等待

2. 避免事務中的使用者互動 ，這樣導致事務時間過長，容易造成死鎖

3. 保持事務簡短並處於一個批處理中，道理和2一樣，儘量讓事務執行時間短。

4. 使用較低的隔離級別，這個看能不能接受髒讀，幻讀等副作用

總結

1. 鎖機制保證併發情況下的資料訪問。

2. 開發中應該儘量利用索引檢索資料，特別是UPDATE/DELETE這種需要排它鎖，應該利用唯一聚集索引欄位更新（通常是主鍵）

3. 規範使用事務能減少死鎖發生

轉發請標明出處：https://www.cnblogs.com/WilsonPan/p/12618849.html

參考文章

事務鎖定和行版本控制指南 - SQL Server | Microsoft Docs