SQL Server 錯誤： 超過了鎖請求超時時段 錯誤1222（Lock Request time out period exceeded）
1、症狀：打開表或者存儲過程，出現異常，查詢過久等
2、解決方案：
- 2.1 最簡單的方法：直接重啟SQL SERVER服務
- 2.2 關閉出現死鎖的進程
--查詢死鎖進程
SELECT blocking_session_id '阻塞進程的ID', wait_duration_ms '等待時間(毫秒)', session_id '(會話ID)' FROM sys.dm_os_waiting_tasks
--關閉死鎖進程
kill spid(進程ID) 或者 exec(kill','spid')
3、原因分析：
3.1 表現：一個用戶A 訪問表A(鎖住了表A)，然后又訪問表B，另一個用戶B 訪問表B(鎖住了表B)，然后企圖訪問表A，這時用戶A由於用戶B已經鎖住表B，它必須等待用戶B釋放表B，才能繼續，好了他老人家就只好老老實實在這等了，同樣用戶B要等用戶A釋放表A才能繼續這就死鎖了。
3.1.1解決方法：
這種死鎖是由於你的程序的BUG產生的，除了調整你的程序的邏輯別無他法
仔細分析你程序的邏輯：
- 3.1.1 盡量避免同時鎖定兩個資源
- 3.1.2 必須同時鎖定兩個資源時，要保證在任何時刻都應該按照相同的順序來鎖定資源.
3.2表現： 用戶A讀一條紀錄，然后修改該條紀錄。這是用戶B修改該條紀錄，這里用戶A的事務里鎖的性質由共享鎖企圖上升到獨占鎖(for update),而用戶B里的獨占鎖由於A有共享鎖存在所以必須等A釋放掉共享鎖，而A由於B的獨占鎖而無法上升的獨占鎖也就不可能釋放共享鎖，於是出現了死鎖。
這種死鎖比較隱蔽，但其實在稍大點的項目中經常發生。
3.2.1 解決方法：
讓用戶A的事務（即先讀后寫類型的操作),在select 時就是用Update lock
語法如下：
select * from table1 with(updlock) where ....
4、其他查詢補充：
--查詢當前活動的鎖管理器資源的信息
SELECT resource_type '資源類型',request_mode '請求模式',request_type '請求類型',request_status '請求狀態',request_session_id '會話ID' FROM sys.dm_tran_locks
--查詢數據庫進程（where 篩選庫）
select spId from master..SysProcesses
where db_Name(dbID) = 'text' and spId <> @@SpId and dbID <> 0
--查詢死鎖表
select request_session_id spid,OBJECT_NAME(resource_associated_entity_id) tableName
from sys.dm_tran_locks where resource_type='OBJECT'
--死鎖相關信息查詢
exec sp_who2 spid
--查看此進程執行的SQL
dbcc inputbuffer(spid)
--查看隔離級別
DBCC USEROPTIONS
創建時間：2020.10.30 更新時間：