关于在SQL语句中no lock的指定

Question

SQL Server 2008 R2select * from table1(no lock) t1,table2(no lock) t2,table3(no lock) t3
where t1.id=t2.id and t3.id=t2select * from table1 t1,table2 t2,table3 t3
where t1.id=t2.id and t3.id=t2
这二者有区别吗?难道这样的select语句也有锁?
问题源于:最近接手别人的项目,看了他的存储过程,几乎所有的多表select查询都显式指定no lock，有必要吗？

Answer 1

所有Select加 With (NoLock)解决阻塞死锁
在查询语句中使用 NOLOCK 和 READPAST 
处理一个数据库死锁的异常时候，其中一个建议就是使用 NOLOCK 或者 READPAST 。有关 NOLOCK 和 READPAST的一些技术知识点： 
对于非银行等严格要求事务的行业，搜索记录中出现或者不出现某条记录，都是在可容忍范围内，所以碰到死锁，应该首先考虑，我们业务逻辑是否能容忍出现或者不出现某些记录，而不是寻求对双方都加锁条件下如何解锁的问题。 
NOLOCK 和 READPAST 都是处理查询、插入、删除等操作时候，如何应对锁住的数据记录。但是这时候一定要注意NOLOCK 和 READPAST的局限性，确认你的业务逻辑可以容忍这些记录的出现或者不出现： 
简单来说： 
NOLOCK 可能把没有提交事务的数据也显示出来． 
READPAST 会把被锁住的行不显示出来 
不使用 NOLOCK 和 READPAST ，在 Select 操作时候则有可能报错误：事务(进程 ID **)与另一个进程被死锁在 锁 资源上，并且已被选作死锁牺牲品。 
下面就来演示这个情况。 
为了演示两个事务死锁的情况，我们下面的测试都需要在SQL Server Management Studio中打开两个查询窗口。保证事务不被干扰。 
演示一 没有提交的事务，NOLOCK 和 READPAST处理的策略： 
查询窗口一请执行如下脚本： 
CREATE TABLE t1 (c1 int IDENTITY(1,1), c2 int) 
go 
BEGIN TRANSACTION 
insert t1(c2) values(1) 
在查询窗口一执行后，查询窗口二执行如下脚本： 
select count(*) from t1 WITH(NOLOCK) 
select count(*) from t1 WITH(READPAST) 
结果与分析： 
查询窗口二依次显示统计结果为： 1、0 
查询窗口一的命令没有提交事务，所以 READPAST 不会计算没有提交事务的这一条记录，这一条被锁住了，READPAST 看不到；而NOLOCK则可以看到被锁住的这一条记录。 
如果这时候我们在查询窗口二中执行： 
select count(*) from t1 就会看到这个执行很久不能执行完毕，因为这个查询遇到了一个死锁。 
清除掉这个测试环境，需要在查询窗口一中再执行如下语句： 
ROLLBACK TRANSACTION 
drop table t1 
演示二：对被锁住的记录，NOLOCK 和 READPAST处理的策略 
这个演示同样需要两个查询窗口。 
请在查询窗口一中执行如下语句： 
CREATE TABLE t2 (UserID int , NickName nvarchar(50)) 
go 
insert t2(UserID,NickName) values(1,'郭红俊') 
insert t2(UserID,NickName) values(2,'蝈蝈俊') 
go 
BEGIN TRANSACTION 
update t2 set NickName = '蝈蝈俊.net' where UserID = 2 
请在查询窗口二中执行如下脚本： 
select * from t2 WITH(NOLOCK) where UserID = 2 
select * from t2 WITH(READPAST) where UserID = 2 
结果与分析： 
查询窗口二中， NOLOCK 对应的查询结果中我们看到了修改后的记录，READPAST对应的查询结果中我们没有看到任何一条记录。 这种情况下就可能发生脏读

Answer 2

LZ可以了解一下事务隔离等级.SQL Server默认的事务隔离等级是read commited(读取认可)..
所以默认不加nolock是需要申请S锁的.加nolock是以read uncommited(读取未认可)..
所以不需加锁.

Answer 3

nolock就可以理解成read uncommited.也就是不加锁，不会有死锁发生

Answer 4

WIHT(NOLOCK)阻止select申请锁，换句话说，就是允许脏读。
未提交读：
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
SELECT * FROM dbo.HR_PERSONS WITH(NOLOCK)
隔离级别最低，允许SELETE读取数据而不需要请求（S）锁，，这样就不会被（X）锁阻塞也不会阻塞（X）锁。允许SELETE读取正在修改中的数据，被称为脏读（dirty read）。适用于数据修改量小，读取数据准确性要求不高的应用程序。
如果事务依赖于SELETE语句读出数据精确性，或者事务不能承受其他事务的并发修改，则不能使用，因为读取数据时没有加锁，索引可能分离，可能导致查询返回的数据中多处或者丢失行，会造成不可预知的情况。
未提交读的意义在于关注报告和业务职能系统，而不是联机事务处理（OLTP）。