Mssql 2000帮助描述：
NOLOCK 不要发出共享锁，并且不要提供排它锁。当此选项生效时，可能会读取未提交的事务或一组在读取中间回滚的页面。有可能发生脏读。仅应用于 SELECT 语句。
那么，Select * From Table with(nolock)语句
在并发访问（同一时间有多个用户访问同一资源）中，会出现以下情况：如果并发用户中有其他用户同时对资源进行了修改，这样对同一数据的访问就会出现“所见不是所得”的情况，从而对其它用户产生某些不利的影响，包括：
1：脏读：有一个用户对某一个资源做了修改，此时另外一个用户正好读取了这条被修改的记录，然后第一个用户又放弃了修改，数据还原到修改之前，这两个不同的结果就是脏读。
2：幻读：特指用户读取一批记录的情况。用户两次查询同一条件的一批记录，第一次查询后，有其它用户对这批数据做了修改，方法可能是insert,update或delete，第二次查询时，用户会发现第一次查询的记录条目有的不在第二次查询结果中，或者是第二次查询的条目不在第一次查询的内容中，造成前后查询结果的不一致。
3：不可重复读：系统中某一个用户的一个操作是一个事务，这个事务分两次读取同一条记录。如果第一次读取后，正好有另外一个用户修改了这条记录，然后第二次读取的正好是之前进行修改记录的那位用户的数据，这样就有可能造成两次读取的数据不同。当然如果我们在事务中锁定这条记录就可以避免。
好处在于提高查询速度，尽管如此，个人建议：尽量少用，视情况使用。
个人认为，可用场景：
1、码表数据：此类数据的插入修改删除频率很低，几乎为0。广泛的说：凡表数据在一定非Select语句的频率低于某一个合理值（此值和实际应用有关），都可以使用nolock来防止并发锁定------此类项目应用最好是非谨慎项目。
2、非谨慎项目的提取业务逻辑。就是此类业务允许脏读。PS：但安全类的数据表，不建议使用nolock，比如密码验证
3、流水型海量数据，在提取时可以采用nolock脏读，来提高性能和用户使用体验。------此类数据最好是非重要数据
4、Exists语句的Select以及在业务（增删修）处理中的Select语句，不要使用nolock，避免出现真正的脏数据。
好东西的使用是有代价的，这个代价必须在承受范围内
good luck！