SQL Server 的鎖機制是為了確保數據的一致性和事務的隔離性而設計的。以下是針對讀寫操作的鎖定行為的詳細說明：
1. 鎖的基本類型
SQL Server 的鎖主要分為以下幾類：
共享鎖（Shared Lock, S Lock）
用於讀操作（如 SELECT）。
允許多個事務同時持有共享鎖，但其他事務不能對同一資源加排他鎖。
鎖定期間，其他事務只能讀取，不能修改。
排他鎖（Exclusive Lock, X Lock）
用於寫操作（如 INSERT, UPDATE, DELETE）。
同一時間只能有一個事務持有排他鎖，且其他事務無法對該資源加任何鎖（包括共享鎖）。
鎖定期間，其他事務既不能讀取也不能修改。
更新鎖（Update Lock, U Lock）
用於潛在的寫操作（例如 UPDATE 前需要先讀取數據）。
更新鎖與共享鎖兼容，但與其他更新鎖或排他鎖不兼容。
目的是防止多個事務同時對同一資源進行更新。
意向鎖（Intent Lock）
表示事務將在更細粒度的層次（如行或頁）上加鎖。
例如：意向排他鎖（IX Lock） 表示事務可能在某行加排他鎖，避免其他事務對整個表加鎖。
2. 讀操作（Read）的鎖定行為
默認行為（取決於隔離級別）
在默認的 READ COMMITTED 隔離級別下：
事務會在讀取數據時加共享鎖（S Lock），並在讀取完成後立即釋放鎖（即使事務未提交）。
這種行為可能導致「不可重複讀」（Non-Repeatable Read）。
不同隔離級別的鎖定差異
READ UNCOMMITTED：不加共享鎖，允許讀取未提交的數據（可能髒讀）。
REPEATABLE READ：共享鎖會持有到事務結束，確保可重複讀。
SERIALIZABLE：對範圍加鎖（鍵範圍鎖），防止幻讀（Phantom Read）。
使用 NOLOCK 提示
sql：
SELECT * FROM Table WITH (NOLOCK)
跳過共享鎖，直接讀取數據（可能讀到未提交或正在修改的數據）。
犧牲一致性換取高並發，需謹慎使用。
3. 寫操作（Write）的鎖定行為
事務在修改數據前，會先嘗試獲取更新鎖（U Lock）（用於定位需修改的數據）。
找到目標數據後，更新鎖會升級為排他鎖（X Lock）。
排他鎖會持有到事務結束（提交或回滾）。
鎖定粒度
默認鎖定粒度為行級鎖（Row-Level Lock）。
若鎖定行數過多，可能觸發鎖升級（Lock Escalation），升級為頁鎖或表鎖。
4. 鎖的兼容性
不同類型的鎖之間的兼容性如下表：
當前鎖模式 請求共享鎖（S） 請求排他鎖（X） 請求更新鎖（U）
共享鎖（S） ✔ ✖ ✔
排他鎖（X） ✖ ✖ ✖
更新鎖（U） ✔ ✖ ✖
共享鎖與更新鎖兼容：允許其他事務讀取數據，但禁止其他更新操作。
排他鎖與所有鎖不兼容：確保寫操作的獨占性。
5. 鎖的粒度（Lock Granularity）
SQL Server 支持多種鎖粒度：
行鎖（Row Lock）：鎖定單行，並發性最高。
頁鎖（Page Lock）：鎖定 8KB 的數據頁。
表鎖（Table Lock）：鎖定整個表，並發性最低。
鍵範圍鎖（Key-Range Lock）：用於 SERIALIZABLE 隔離級別，防止幻讀。
鎖粒度由 SQL Server 動態管理，通常無需手動干預。
6. 死鎖（Deadlock）
兩個事務互相等待對方釋放鎖。
解決機制：SQL Server 會自動檢測死鎖，並選擇一個事務作為「犧牲者」回滾。
避免方法：
保持事務簡短，減少鎖持有時間。
按相同順序訪問資源（例如先表A後表B）。
使用 SET DEADLOCK_PRIORITY 控制優先級。
7. 監控鎖定
動態管理視圖（DMV）
sql
– 查看當前鎖定狀態
SELECT * FROM sys.dm_tran_locks;
– 查看阻塞的會話
SELECT * FROM sys.dm_os_waiting_tasks;
Profiler / Extended Events
可追蹤 Lock:Acquired 和 Lock:Released 事件。
8. 實踐
選擇合適的隔離級別：避免過度使用 SERIALIZABLE。
避免長事務：減少鎖持有時間。
使用索引：精確鎖定目標數據，減少鎖升級。
考慮行版本控制（如 READ_COMMITTED_SNAPSHOT）：通過版本隔離避免讀寫阻塞。
通過理解鎖的行為，可以更好地設計事務和優化並發性能，同時避免阻塞和死鎖問題。
附: SQL SERVER Transaction的隔离级别
)
