NOLOCK的使用
NOLOCK可以忽略锁，直接从数据库读取数据。这意味着可以避开锁，从而提高性能和扩展性。但同时也意味着代码出错的可能性存在。你可能会读取到运行事务正在处理的无须验证的未递交数据。这种风险可以量化。
如果是金融方面的代码或者一些非常规的总计(你想绝对保证安全性)，你应该小心行事并且不使用这种技术。但是我认为使用该技术会比你90%应用系统性能要好，当用户(或者是交互代码)
发现一个未递交的修改时，使用该技术会保证不会像未使用该技术那样引起大麻烦。实际上，你可能发现你的大多数数据很少或者甚至不进行修改的，这样我们就不会因为这些数据被锁住而浪费大量的时间。
例如，如果你想统计在2009年6月到8月之间某网站的注册用户，就没有理由去锁住任何记录：2009年9月1号一到来，这个用户数就是确定的。
ROWLOCK的使用
ROWLOCK告诉SQL
Server只使用行级锁。ROWLOCK语法可以使用在SELECT,
UPDATE和DELETE语句中，不过
我习惯仅仅在UPDATE和DELETE语句中使用。如果在UPDATE语句中有指定的主键，那么就总是会引发行级锁的。但是当SQL
Server对几个这种UPDATE进行批处理时，某些数据正好在同一个页面(page)，这种情况在当前情况下
是很有可能发生的，这就象在一个folder中，创建一个新文件需要较长的时间，而同时你又要去更新该folder中的某些文件。当页面锁引发后，事情就开始变得糟糕了。而如果在UPDATE或者DELETE 时，没有指定主键，数据库当然认为很多数据会收到影响，那样
就会直接引发页面锁，事情同样变得糟糕。
通过指定使用行级锁，这种情况可以得到避免。但是需要小心的是，如果你错误地使用在过多行上，数据库并不会聪明到自动将行级锁升级到页面锁，服务器也会因为行级锁的开销而消耗大量的内存和CPU，直至无法响应。尤其主要留意的是企业管理器中"管理/当前活动"(Management /Current
Activity)这一项。该项会花较长的时间来载入锁的信息。这些信息是十分有用的，当你使用行级锁后，你如果在"锁/处理" (Locks/Processes)下看到几百个锁，一点都不奇怪，而恰恰应该庆幸锁超时和死锁的问题减少了。
注意事项
我认为SQL
Server倾向于使用NOLOCK关键字，而ROWLOCK关键字由用户根据情况自行决定。你可以仅仅在
SELECT语句中使用NOLOCK，这些SELECT语句场合包括Join查询，以及在INSERT语句中的SELECT使用，例如：
SELECT
COUNT(U.UserID)
FROM
Users
U
WITH
(NOLOCK)
innerjoin
UsersInUserGroups
UG
WITH
(NOLOCK)
ON
U.UserID
=
UG.UserID
NOLOCK
和
ROWLOCK的使用效果
很难去量化在使用NOLOCK和ROWLOCK后，Streamload.com网站给我们了一个信息。使用NOLOCK和ROWLOCK 前，Streamload.com的速度很慢，而且经常无法使用，以及很不稳定。使用后，就变得快速、容易访问以及稳定了。两者简直就是天壤之别。这些改变当然无法在
关于锁的文档中很难找到。那些文档会建议你重写你的应用，当表数据被使用，锁产生了(没错，就是这样)，然后你应该使用小事务并且以批处理的形式执行(不错，实际经验就是如此)，使用低级别的隔离措施
(也没错，NOLOCK就是一个极端的例子)，还建议你有限的连接，从而让处理器进行合作(好复杂的描述，而且总觉得怪怪的不像个好点子)。我不知道是否用数据库咨询师会提到本文中的技术(或类似的技术)，
但是我只想说的是，Streamload.com的运行状况的确因为该技术得到了改善。如果你遇到了锁争用的问题，也可以试试NOLOCK和ROWLOCK。
申明
是否使用NOLOCK和ROWLOCK，需要自行判断，并谨慎运用。我用该技术的情况是：在并发性很高的数据库中select自己想要的数据。我需要判断如果用NOLOCK而引起一些返回的不准确，或者ROWLOCK是否会造成太多的锁，这些情况出现时，对于访问者或者使用者来说，是否是可以接受的。在大多数情况下，我认为是没有问题的，但是也许你的代码不适用，你需要小心对待。你需要创建一些独立的过程，是否加锁，如何加锁，以作为对比。当 UPDATE
或者
DELETE查询影响到很多数据行时，你在使用PAGELOCK,
TABLOCK时也会遇到别的问题.
NOLOCK可以忽略锁，直接从数据库读取数据。这意味着可以避开锁，从而提高性能和扩展性。但同时也意味着代码出错的可能性存在。你可能会读取到运行事务正在处理的无须验证的未递交数据。
如果是金融方面的代码或者一些非常规的总计(你想绝对保证安全性)，你应该小心行事并且不使用这种技术。但是我认为使用该技术会比你90%应用系统性能要好，当用户
例如，如果你想统计在2009年6月到8月之间某网站的注册用户，就没有理由去锁住任何记录：
ROWLOCK的使用
ROWLOCK告诉
通过指定使用行级锁，这种情况可以得到避免。但是需要小心的是，如果你错误地使用在过多行上，数据库并不会聪明到自动将行级锁升级到页面锁，服务器也会因为行级锁的开销而消耗大量的内存和CPU，直至无法响应。尤其主要留意的是
注意事项
我认为SQL
SELECT
inner
NOLOCK
很难去量化在使用NOLOCK和ROWLOCK后，Streamload.com网站给我们了一个信息。
申明
是否使用NOLOCK和ROWLOCK，需要自行判断，并谨慎运用。我用该技术的情况是：在并发性很高的数据库中select自己想要的数据。我需要判断如果用NOLOCK
UPDLOCK 读取表时使用更新锁，而不使用共享锁，并将锁一直保留到语句或事务的结束。UPDLOCK 的优点是允许您读取数据（不阻塞其它事务）并在以后更新数据，同时确保自从上次读取数据后数据没有被更改。 这是SqlServer2000中对更新锁的说明.
当我们用UPDLOCK来读取记录时可以对取到的记录加上更新锁，从而加上锁的记录在其它的线程中是不能更改的只能等本线程的事务结束后才能更改，我如下示例：BEGIN TRANSACTION --开始一个事务
SELECT Qty
FROM myTable WITH (UPDLOCK)
WHERE Id in (1,2,3)
UPDATE myTable SET Qty = Qty - A.Qty
FROM myTable AS A
INNER JOIN @_Table AS B ON A.ID = B.ID
COMMIT TRANSACTION --提交事务 这样在更新时其它的线程或事务在这些语句执行完成前是不能更改ID是１，２，３的记录的．其它的都可以修改和读，１，２，３的只能读，要是修改的话只能等这些语句完成后才能操作.从而保证的数据的修改正确.
SELECT Qty
FROM myTable WITH (UPDLOCK)
WHERE Id in (1,2,3)
UPDATE myTable SET Qty = Qty - A.Qty
FROM myTable
INNER JOIN
COMMIT TRANSACTION --提交事务 这样在更新时其它的线程或事务在这些语句执行完成前是不能更改ID是１，２，３的记录的．其它的都可以修改和读，１，２，３的只能读，要是修改的话只能等这些语句完成后才能操作.从而保证的数据的修改正确.