主页 / user-87836

Forrest's questions

Martin Hope
Forrest
Asked: 2019-07-30 08:20:41 +0800 CST
  • 13

问题

我有一对查询，在可序列化的隔离下，会导致 RX-X 锁定。但是，当我使用扩展事件观看锁获取时，RX-X 锁获取永远不会出现，它只是被释放。它从何而来？

复制品

这是我的桌子：

CREATE TABLE dbo.LockTest (
ID int identity,
Junk char(4)
)

CREATE CLUSTERED INDEX CX_LockTest --not unique!
ON dbo.LockTest(ID)

--preload some rows
INSERT dbo.LockTest
VALUES ('data'),('data'),('data')

这是我的问题批次：

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE

BEGIN TRAN

INSERT dbo.LockTest
VALUES ('bleh')

SELECT *
FROM dbo.LockTest
WHERE ID = SCOPE_IDENTITY()

--ROLLBACK

我检查了这个会话持有的锁，并查看了 RX-X：

SELECT resource_type, request_mode, request_status, resource_description
FROM sys.dm_tran_locks
WHERE request_session_id = 72 --change SPID!

dm_tran_locks

lock_acquired但我在和上也有一个扩展事件lock_released。我在适当的 associated_object_id 上对其进行过滤……没有 RX-X。

扩展事件输出

执行回滚后，我看到 RX-X (LAST_MODE) 已释放，即使它从未被获取。

LAST_MODE

我试过的

  • 我查看了扩展事件中的所有锁 - 没有过滤。未获得 RX-X 锁。

  • 我也尝试了 Profiler: 相同的结果（当然除了它的名字是正确的......没有“LAST_MODE”）。

  • 我运行 XE 进行锁定升级 - 它不存在。

  • 没有专门用于转换的 XE，但我能够确认至少 U 到 X 锁定转换是由lock_acquired

另外值得注意的是被收购但从未发布的 RI-N。我目前的假设是 RX-X 是转换锁，如此处所述。我的批次中有重叠的键范围锁，看起来它们应该有资格进行转换，但 RX-X 锁不在转换表中。

这个锁是从哪里来的，为什么不被扩展事件拾取？

sql-server locking
Martin Hope
Forrest
Asked: 2018-05-22 14:21:59 +0800 CST
  • 14

我在当前环境中与 NOLOCK 作斗争。我听到的一个论点是锁定的开销会减慢查询速度。因此，我设计了一个测试来查看此开销可能有多少。

我发现 NOLOCK 实际上减慢了我的扫描速度。

起初我很高兴，但现在我只是感到困惑。我的测试不知何故无效吗？NOLOCK 实际上不应该允许稍微快一点的扫描吗？这里发生了什么事？

这是我的脚本：

USE TestDB
GO

--Create a five-million row table
DROP TABLE IF EXISTS dbo.JustAnotherTable
GO

CREATE TABLE dbo.JustAnotherTable (
ID INT IDENTITY PRIMARY KEY,
notID CHAR(5) NOT NULL )

INSERT dbo.JustAnotherTable
SELECT TOP 5000000 'datas'
FROM sys.all_objects a1
CROSS JOIN sys.all_objects a2
CROSS JOIN sys.all_objects a3

/********************************************/
-----Testing. Run each multiple times--------
/********************************************/
--How fast is a plain select? (I get about 587ms)
DECLARE @trash CHAR(5), @dt DATETIME = SYSDATETIME()

SELECT @trash = notID  --trash variable prevents any slowdown from returning data to SSMS
FROM dbo.JustAnotherTable
ORDER BY ID
OPTION (MAXDOP 1)

SELECT DATEDIFF(MILLISECOND,@dt,SYSDATETIME())

----------------------------------------------
--Now how fast is it with NOLOCK? About 640ms for me
DECLARE @trash CHAR(5), @dt DATETIME = SYSDATETIME()

SELECT @trash = notID
FROM dbo.JustAnotherTable (NOLOCK)
ORDER BY ID --would be an allocation order scan without this, breaking the comparison
OPTION (MAXDOP 1)

SELECT DATEDIFF(MILLISECOND,@dt,SYSDATETIME())

我尝试过但没有用的：

  • 在不同的服务器上运行（相同的结果，服务器是 2016-SP1 和 2016-SP2，都安静）
  • 在不同版本的 dbfiddle.uk上运行（嘈杂，但结果可能相同）
  • 设置隔离级别而不是提示（相同的结果）
  • 关闭表上的锁升级（相同的结果）
  • 检查实际查询计划中扫描的实际执行时间（相同结果）
  • 重新编译提示（相同的结果）
  • 只读文件组（相同结果）

最有前途的探索来自删除垃圾变量和使用无结果查询。最初这显示 NOLOCK 稍快一些，但当我向我的老板展示演示时，NOLOCK 又变慢了。

NOLOCK 减慢变量赋值扫描的原因是什么？

sql-server sql-server-2016