前言：看了宋桑的文章《一次意外的X鎖不阻塞問題》，結合本人的測試，說明一下我對select中使用X鎖是否會持有到事務結束產生的誤區；

詳情不多說了，詳見宋桑的《一次意外的X鎖不阻塞問題》和《消失的共享鎖》，對Select+X鎖和Select+S鎖的情況進行了解釋。以下只描述我的測試；測試表結構及數據如下：

 1 /****** Script for SelectTopNRows command from SSMS  ******/ 2 CREATE TABLE [test_a].[dbo].[tmp_byxl_01](id INT IDENTITY,flag int) 3 INSERT INTO [test_a].[dbo].[tmp_byxl_01](flag) VALUES(null) 4 go 7 5 UPDATE [test_a].[dbo].[tmp_byxl_01] SET flag=id  6  7 SELECT TOP 1000 [id] 8       ,[flag] 9   FROM [test_a].[dbo].[tmp_byxl_01]10 11 12 -------------------------------13 id          flag14 ----------- ----15 1           116 2           217 3           318 4           419 5           520 6           621 7           722 23 (7 行受影響)

由于案例出自系統續費問題，業務采用的是調用存儲過程的方式實現，因此每一次調用時，都是select+X鎖的方式；這和上述文章中提到的“Select+X鎖和Select+S鎖”的情況不太相同

先說我的誤區

誤區：select中指定的X鎖將在查詢結束后立即釋放，并不持續到tran結束

測試代碼如下：

--session_ABEGIN TRANSELECT * FROM [test_a].[dbo].[tmp_byxl_01](xlock) WHERE flag=2  WAITFOR DELAY '00:00:10'COMMIT--Session_BBEGIN TRANSELECT * FROM [test_a].[dbo].[tmp_byxl_01](xlock) WHERE flag=2COMMIT

由于兩個tran都是申請xlock，在執行時，Session_A(spid=53)先執行，Session_B(spid=55)大約5秒后執行，通過SP_LOCK可以看到，spid=55申請X鎖時被阻塞