sql - 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 {} 更好

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

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

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

参考

SELECT 语句中 NOLOCK 提示的效果

什么时候应该使用“with (nolock)”

在 SQL Server 中使用 NOLOCK 和 READPAST 表提示（作者 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-上有关于 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 语句，则修改后的数据将包含在结果集中。

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) 和 without hints 之间是否有任何性能优势。结果表明，ReportQuery 在大约 28 秒内持续运行，平均迭代时间为 1.5 秒，没有显着差异。

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

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

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

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

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

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

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

'报告查询'</p>

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'