SQL Server数据表提示NOLOCK和READPAST

当对数据库中的数据进行读操作或修改时，数据库引擎使用专门的控制类型来保持数据库的完整性，称为锁机制。锁机制通过确保包含在一个事务中的数据库记录在该事务提交之前不能被其它事务修改来保证数据库的一致性。

在设计数据库应用时，你应该记住各种不同类型的锁及事务发生的不同隔离级别。通常情况下，SQL Server默认方式能够很好地完成你要使用的功能，不过，有些时候利用SQL语句在数据表上手工添加关于锁是如何应用的提示信息将是十分有用的。

本文主要介绍了两种数据表提示：NOLOCK和READPAST。我们将建立一个数据表用作例子中的查询数据表。执行列表A中的脚本建立一个SalesHistory数据表并添加一些数据。

NOLOCK

该数据表提示，也称为READUNCOMMITTED，只能用于SELECT语句。NOLOCK表明没有对数据表添加共享锁以阻止其它事务对数据表数据的修改。

该语句的好处是它可以使数据库引擎不用在处理查询中的上锁问题，可以提高并发性并改善数据库性能，因为数据库引擎不用在维护共享锁的使用问题。存在的问题是因为该语句不能处理要读取的数据表的所有锁，所以一些“脏数据”或未被提交的数据潜在的可能被读取。

如果某个事务被滚回，那么应用了NOLOCK连接的数据读取操作将可以读取未提交的数据。这种类型的读取导致处理的不一致性会带来很多问题。这是你使用NOLOCK时应该了解的技巧。

作为一个负面影响，NOLOCK查询还可能带来读取“幻影”数据或读取在一个数据库读取事务中可以获得的但在另一个事务中可能被滚回的数据的风险。（我将在本系列文章的第二部分对这个负面影响进行详细说明。）

下面的例子展示了NOLOCK如何工作以及脏数据读取是如何产生的。在下面的脚本中，我用一个事务在SalesHistory数据表中插入一条记录。

BEGIN TRANSACTION

INSERT INTO SalesHistory

(Product, SaleDate, SalePrice)

VALUES

('PoolTable', GETDATE(), 500)

这个事务仍旧是开放的，这意味着仍可以对插入数据表的记录上锁以阻止其它操作。在一个新的查询窗口中，运行下面的脚本，该脚本使用NOLOCK数据表提示返回SalesHistory数据表中的记录数。

SELECT COUNT(*) FROM SalesHistory WITH(NOLOCK)

返回记录数值为301。因为对SalesHistory数据表插入记录的事务还没有提交，所以我们可以撤销它。我通过使用下面的语句将事务滚回：

ROLLBACK TRANSACTION

该语句从SalesHistory数据表中删除前面插入的记录。现在我们运行前面运行的同样的SELECT语句。

SELECT COUNT(*) FROM SalesHistory WITH(NOLOCK)

这次返回记录数的值为300。我第一次查询读记录的事务还没有提交，这就是一个脏数据读取。