添加 nolock 后速度慢了一倍有余

今天在优化语句是发现了很有意思的现象，平常的SELECT语句，都加上了NOLOCK提示，提高并发度减少阻塞，速度比没有加NOLOCK能明显感觉快，

今天的主要的两个表一个为24G，另一个为34G，行数为2千多万行。主要资源消耗在如下的SQL语句：

select orderID from bigtable(nolock)b
inner join from biggertable(nolock) bt 
on b.orderid=bt.orderid
where tb.orderDate <somedatetime 
and tb.orderDate>somedatetime
and tb.type in(3,4,5,6,7,8) 

查询的数据都在索引中，有三个索引，分布在type,orderdate,orderid上，通过索引的交叉，可以得到所需的数据，耗时4分20秒，限制是不能

添加修改索引，因为该数据库每天被还原一次，只能改动语句写法。照道理，如果我运行2次以上，那第二次的physical reads ,read-ahead reads

应该为0才是，本机的内存是足够的，理论上可以容纳所需的 data page，但是每次运行的时候 physical reads 没有什么明显的变化。

当我把nolock去掉时，这次运行的时间为2分19秒，运行几次都是2分多，这是打开set statistics io on 开关，发现第二次以后的physical reads,

read-ahead reads 都是0次。

当我使用nolock时，其它update事务导致这些data page 读到内存中后因为内存的压力，重新写入到磁盘中了，毕竟这两者可以同时进行，而当我去掉nolock时，

因为有S锁，导致update被阻塞，变相起到了保留相应datapage在内存的目的。

结论是：千万不要迷信nolock，以为一起性能问题都可用之来缓解。nolock可以在数据仓库，静态表中可以安全的使用！

关于nolock导致的问题，可以看如下的文章。

Previously committed rows might be missed if NOLOCK hint is used