在什么情况下(行锁)不能在视图上工作？

Question

我们在一个客户网站上有一个锁连环问题。通过各种工具的组合，我们成功地找到了根锁。它肯定是在锁堆时运行这个特定的SQL语句：

INSERT INTO #Gather
SELECT (columns omitted for brevity)
  FROM dbo.vScheduleInsuranceRuleViolations WITH(rowlock) OPTION (MAXDOP 1)

锁层次分析得出了一个不可避免的结论：WITH (rowlock)在这里没有做任何有用的事情。

这一观点很长，正确地说需要很长时间来评估。有几个调用者只在筛选WHERE子句(大多数DB或少数记录)和锁/并发需求方面有所不同。在这个特定的调用者中，我们有最差的过滤器和最低的锁需求(WITH (rowlock) In READ COMMITTED - READ UNCOMMITTED在这里不能工作)。

在我将视图定义复制并粘贴到调用者之前，我想知道为什么如果可能的话，它不能工作；因为我希望WITH (rowlock)应用于视图中读取的每个表。

Answer 1

起点

rowlock提示的有趣之处在于，存储引擎可以自由地忽略它们。来自丢失共享锁的案例：

这里描述的锁优化的一个有趣的副作用是，使用页锁的查询可能会阻塞使用行锁提示的相同查询。(我说“可能不是”，因为ROWLOCK确实是一种暗示，而不是指令--存储引擎可能会也可能不会尊重它。)这并不是说您应该立即向所有SELECT查询添加行锁提示--这可能是一个非常糟糕的主意--但是您应该意识到这种锁定优化是存在的。