它会更快，因为它不需要等待锁

1)是的，NOLOCK的选择比普通的选择完成得更快。

2)是的，使用NOLOCK的select将允许对受影响表的其他查询比普通select更快地完成。

为什么会这样?

NOLOCK通常(取决于你的DB引擎)意味着给我你的数据，我不关心它处于什么状态，当你从它读取时，不要费心保持它不动。它速度更快，资源消耗更少，同时也非常非常危险。

You should be warned to never do an update from or perform anything system critical, or where absolute correctness is required using data that originated from a NOLOCK read. It is absolutely possible that this data contains rows that were deleted during the query's run or that have been deleted in other sessions that have yet to be finalized. It is possible that this data includes rows that have been partially updated. It is possible that this data contains records that violate foreign key constraints. It is possible that this data excludes rows that have been added to the table but have yet to be committed.

你真的没有办法知道数据的状态是什么。

如果您试图获得诸如行计数或其他可接受误差范围的汇总数据，那么NOLOCK是提高这些查询性能并避免它们对数据库性能产生负面影响的好方法。

总是非常谨慎地使用NOLOCK提示，并以可疑的方式对待它返回的任何数据。

NOLOCK使大多数SELECT语句更快，因为缺少共享锁。此外，不发放锁意味着写入器不会受到SELECT的阻碍。

NOLOCK在功能上等同于READ UNCOMMITTED的隔离级别。主要的区别是，如果您愿意，可以在某些表上使用NOLOCK，但不能在其他表上使用。如果您计划对复杂查询中的所有表使用NOLOCK，那么使用SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED更容易，因为您不必对每个表应用提示。

这里是关于您可以使用的所有隔离级别的信息，以及表提示。

设置事务隔离级别

表提示(Transact-SQL)

除了上面所说的，你应该非常清楚，nolock实际上强加了你无法获得在你选择之前已经提交的行的风险。

参见http://blogs.msdn.com/sqlcat/archive/2007/02/01/previously-committed-rows-might-be-missed-if-nolock-hint-is-used.aspx

The answer is Yes if the query is run multiple times at once, because each transaction won't need to wait for the others to complete. However, If the query is run once on its own then the answer is No. Yes. There's a significant probability that careful use of WITH(NOLOCK) will speed up your database overall. It means that other transactions won't have to wait for this SELECT statement to finish, but on the other hand, other transactions will slow down as they're now sharing their processing time with a new transaction.

注意，对于有聚集索引的表，只能在SELECT语句中使用WITH (NOLOCK)。

WITH(NOLOCK)经常被用作加速数据库读事务的神奇方法。

结果集可以包含尚未提交的行，这些行稍后通常会回滚。

如果WITH(NOLOCK)应用于具有非聚集索引的表，那么行索引可以由其他事务更改，因为行数据正在流到结果表中。这意味着结果集可能缺少行或多次显示同一行。

READ COMMITTED增加了一个额外的问题，即多个用户同时更改同一单元格时，单个列内的数据被损坏。