SQL 2008+ NOLOCK 与 READPAST 报告准确性的注意事项

Question

理解最终决策就是业务决策，SQL 2008 R2 中运行NOLOCK & READPAST 之间的准确性考虑是什么？在与业务领域讨论变化之前，我想有一个更好的了解。

我继承了许多查询，用于为管理报告创建数据 View 。 “WITH (NOLOCK)”被广泛使用但不一致。正在读取的数据来自不断更新的广泛使用的应用程序的生产服务器。我们正在从 SQL 2005 服务器迁移到 SQL 2008 R2 服务器。这些报告希望数据比存档服务器上 24 小时的旧数据更新鲜。 NOLOCK 的使用表明过去的决定；存在冲突的可能性，精度损失是可以接受的。数据用于填充用于人类意识/决策的仪表板。

所有查询都是 SELECT，对数据 View 登录具有只读访问权限。大多数查询是单表，只有少数 2 和 3 表连接。鉴于低级别的连接 WITH () 似乎是比 SET TRANSACTION ISOLATION LEVEL {} 更好的选择

表提示 (Transact-SQL) http://msdn.microsoft.com/en-us/library/ms187373.aspx(以及关于 SO 的多个问题)表示，除了丢失锁定记录之外，NOLOCK 和/或 READUNCOMMITTED 可能存在重复读取问题。

READPAST 看起来更准确，因为它只会错过锁定的记录而不会出现重复的情况。但我不确定它和 NOLOCK 之间丢失锁定记录的级别是否一致。

Tim Chapman 有一篇比较两者的好文章，但它写于 2007 年，大部分评论围绕 2000 年和 2005 年，其中一条评论表明 READPAST 在 2008 R2

引用

Effect of NOLOCK hint in SELECT statements

When should you use "with (nolock)"

Using NOLOCK and READPAST table hints in SQL Server (By Tim Chapman)

编辑:

下面的两个答案中建议使用快照隔离。快照隔离是数据库的相关设置，这个 Q/A https://serverfault.com/questions/117104/how-can-i-tell-if-snapshot-isolation-is-turned-on 描述了如何查看数据库上的设置。我现在知道它已禁用，我正在阅读来自主要应用程序数据库的报告。更改设置不是一个选项。 +- 百分之几的准确度是可以接受的，应用程序 (OLTP) 影响是 Not Acceptable 。大多数简单查询不需要考虑锁，但在某些极端情况下，需要考虑锁。随着 SQL 2005 快照隔离的出现，关于 SQL 2008 或更高版本中的 NOLOCK & READPAST 行为的信息很少。然而，它们仍然是我唯一的选择。

Answer 1

一个值得考虑的更好的选择是为数据库本身启用 READ COMMITTED SNAPSHOT。这使用 tempdb 中的版本控制来捕获事务开始时表的状态。

在 http://www.brentozar.com/archive/2013/01/implementing-snapshot-or-read-committed-snapshot-isolation-in-sql-server-a-guide/ 上有关于 NOLOCK、READPAST 等各个方面的非常好的阅读

如果在您从中选择时有人正在更新表，则 WITH (NOLOCK) 可能会提供不正确的结果。如果在读取表时由于插入而导致页面拆分，并且新页面恰好超出了您已读取的点，则 WITH (NOLOCK) 将已经从旧页面返回行，然后将返回重复新页面中的行。这只是 (NOLOCK) 不好的一个例子。
WITH (READPAST) 将跳过在您从表中读取时正在更新或插入的任何记录。在繁忙的数据库中，这两种选择都不好。

鉴于最近对您的问题进行的编辑，您声明您不能更改 READ COMMITTED SNAPSHOT 的数据库设置，也许您应该考虑使用存储过程来为您的报告收集数据，并在存储过程的开始使用设置事务隔离级别SET TRANSACTION ISOLATION LEVEL SNAPSHOT; 。为此，您需要更改数据库选项“允许快照隔离”。

来自 SQL Server 联机丛书:

快照

指定事务中任何语句读取的数据将是事务开始时存在的数据的事务一致版本。事务只能识别在事务开始之前提交的数据修改。当前事务开始后其他事务所做的数据修改对当前事务中执行的语句是不可见的。效果就像事务中的语句获取事务开始时存在的已提交数据的快照一样。

除了正在恢复数据库时，SNAPSHOT 事务在读取数据时不会请求锁定。 SNAPSHOT 事务读取数据不会阻止其他事务写入数据。写入数据的事务不会阻止 SNAPSHOT 事务读取数据。

在数据库恢复的回滚阶段，如果尝试读取被正在回滚的另一个事务锁定的数据，则 SNAPSHOT 事务将请求锁定。 SNAPSHOT 事务被阻塞，直到该事务被回滚。锁定被授予后立即释放。

在启动使用 SNAPSHOT 隔离级别的事务之前，必须将 ALLOW_SNAPSHOT_ISOLATION 数据库选项设置为 ON。如果使用 SNAPSHOT 隔离级别的事务访问多个数据库中的数据，则必须在每个数据库中将 ALLOW_SNAPSHOT_ISOLATION 设置为 ON。

不能将事务设置为以另一个隔离级别启动的 SNAPSHOT 隔离级别；这样做将导致事务中止。如果事务以 SNAPSHOT 隔离级别启动，您可以将其更改为另一个隔离级别，然后再回到 SNAPSHOT。事务在第一次访问数据时开始。

在 SNAPSHOT 隔离级别下运行的事务可以查看该事务所做的更改。例如，如果事务对表执行 UPDATE，然后针对同一个表发出 SELECT 语句，则修改后的数据将包含在结果集中。