2

我在 Microsoft SQL Server 2014 上有一个数据库，其中READ_COMMITTED_SNAPSHOT属性已打开。我理解这意味着读取不会被写入阻塞，因为读取不会发出共享锁，这是干净的读取。

我的问题是：WITH (NOLOCK)在这种情况下使用 in select 语句是否可以获得任何性能提升？就我而言，我不介意阅读会很脏。

我试图找到这些信息，但只找到了使用WITH (NOLOCK)和READ_COMMITTED_SNAPSHOT开启之间的比较。但我已经戴上了。

4

3 回答 3

1

谢谢大家的建议。

我们已经进行了一些测试，看起来WITH (NOLOCK)即使READ_COMMITTED_SNAPSHOT打开，使用仍然会产生性能差异。

测试用例是：大量更新事务中的某些表（更新 3M 记录），同时从另一个连接中的同一个表读取。在此读取语句中使用或不使用WITH (NOLOCK)会产生巨大的性能差异（使用WITH (NOLOCK)更快）。

于 2017-09-01T07:33:37.807 回答
1

理论上应该有改进，因为尽管查询在任何一种情况下都不会阻塞，但在这种READ_COMMITTED_SNAPSHOT情况下仍然需要与锁关联的簿记，以便数据库知道何时需要创建/保留/清理快照行/页。

但是，与所有性能问题一样，您应该尝试一下，看看在实践中是否存在差异，如果存在差异，是否对您的用例很重要。

于 2017-08-29T12:35:27.167 回答
-1

但请注意 Azure DB！我们有 NOLOCK（从内部部署开始），并发现在某些情况下他们发送了 Azure DB berzerk：即以前运行良好的查询（使用 NOLOCK）在 Azure DB 上运行非常缓慢，直到我们删除了 NOLOCK。这与所有建议和所有文档、所有理论等都背道而驰。但是 Azure DB 是一头奇怪的野兽，理论在实践中仍然经常不成立。

于 2019-05-21T08:18:03.020 回答