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

Question

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

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

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

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

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

Tim Chapman 有一篇很好的文章比较了两者，但它写于 2007 年，大多数 cmets 围绕 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) 影响是不可接受的。大多数简单查询不需要考虑锁定，但在某些极端情况下，需要考虑锁定。随着 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/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 事务被阻塞，直到该事务被回滚。锁被授予后立即释放。

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

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

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

Answer 2

NOLOCK 可能会导致读取重复数据、丢失数据以及查询实际上失败并显示错误消息（与“数据移动”有关）。

另一方面，非NONLOCK 查询可能也读取重复数据和错误数据！它绝不是数据库的一致快照。不同的是它不会读取未提交的数据，永远不会失败。

NOLOCK 的问题主要是它可以随机失败，所以你需要重试。另外，读取错误数据的概率略高。

NOLOCK 在进行表扫描时有一个很大的优势：SQL Server 可以使用分配顺序扫描而不是索引顺序扫描。 TABLOCK 具有相同的效果。在存在碎片的情况下，这可以显着加快速度。

考虑只使用快照隔离级别，因为它消除了所有这些问题。它带有其他一些权衡，并且您不会获得分配顺序扫描。但它永久且全面地消除了锁定问题。

Answer 3

在使用 SQLQueryStress http://www.datamanipulation.net/sqlquerystress/ 进行压力测试后回答我自己的问题（这是一个非常好用的工具）。 SQLQueryStress 的结果针对 SQL Server Profiler 进行了测试；精度与 SQL Server Profiler 相同，尽管进动少了小数点后两位（但对于此测试来说已经足够了）。

如问题中所述，主要关注点是应用程序性能影响，报告准确性和性能是次要考虑因素。所有测试都发生在测试应用程序处于活动状态并且有一些次要活动的测试服务器上。

下载并熟悉 SQLQueryStress 后，我设置了一个简单的“ReportQuery”来充当资源猪。它设置为使用 15 个线程运行 15 次迭代（总共 225 个查询）。总运行时间约为 28 秒，平均迭代时间为 1.49 秒。

创建了一个添加/删除“ApplicationQuery”来表示正在进行的应用程序活动。它设置为使用 1 个线程运行 2000 次迭代。有两个版本，带有 select 语句（运行 31 秒）和不带 select 语句（运行 28 秒）。这些代表正常的高峰时间应用程序活动。

“ReportQuery”三个版本中的每一个都运行 10 次测试运行，这是为了确定在“with(nolock)”、“with(readpast)”和“没有提示”之间是否有任何性能优势。结果表明，ReportQuery 在大约 28 秒内持续运行，平均迭代时间为 1.5 秒，没有显着差异。

没有大的异常值，因此决定为以下测试减少到 5 次测试运行。

使用 select 语句对 ApplicationQuery 进行 5 次测试；三个版本的“ReportQuery”中的一个也在运行。在 15 次总计测试中，手动启动 ApplicationQuery，之后立即手动启动 ReportQuery。此场景表示资源繁重的报告查询与应用程序正在进行的资源活动相冲突。

重复了测试运行，但这次使用 ApplicationQuery 没有选择语句。

结果：在每种情况下，ApplicationQuery 都被限制为几乎没有前进的进度，而 ReportQuery 正在运行。

在使用多个 ApplicationQuery 对数据库进行资源争夺时，ReportQuery 没有明显的性能损失。

ApplicationQuery 能够与 ReportQuery 并行运行查询，但在争夺资源时进度非常缓慢。本质上，运行 2000 个应用程序添加/删除查询的总时间被 ReportQuery 使用的时间延长了。

最初的问题是关于哪个更准确，变得毫无意义。使用或不使用提示 NOLOCK 或 READPAST 之间基本上没有报告或应用程序性能差异，因此不要在繁忙的数据库中使用并尽可能获得最高准确度。

‘报告查询’

select 
ID
, [TABLE_NAME]
, NUMBER
, FIELD
, OLD_VALUE
, NEW_VALUE
, SYSMODUSER
, SYSMODTIME
, SYSMODCOUNT

from dbo.UPMCINCIDENTMGMTAUDITRECORDSM1 

where Number like '%'
or NUMBER like '2010-01-01'

‘ApplicationQuery’（带有 Select 语句）

select * 

from dbo.UPMCINCIDENTMGMTAUDITRECORDSM1 
where FIELD = 'JJTestingPerformance'


insert into dbo.UPMCINCIDENTMGMTAUDITRECORDSM1 (ID
, [TABLE_NAME]
, NUMBER
, FIELD
, OLD_VALUE
, NEW_VALUE
)

values ('Test+Time'
, 'none'
, 'tst01'
, 'JJTestingPerformance'
, 'No Value'
, 'Test'
)

delete from dbo.UPMCINCIDENTMGMTAUDITRECORDSM1

where FIELD = 'JJTestingPerformance'

‘ApplicationQuery’（不带 Select 语句）

insert into dbo.UPMCINCIDENTMGMTAUDITRECORDSM1 (ID
, [TABLE_NAME]
, NUMBER
, FIELD
, OLD_VALUE
, NEW_VALUE
 )

values ('Test+Time'
, 'none'
, 'tst01'
, 'JJTestingPerformance'
, 'No Value'
, 'Test'
)

delete from dbo.UPMCINCIDENTMGMTAUDITRECORDSM1

where FIELD = 'JJTestingPerformance'