sql server 性能优化之nolock

在SQL Server数据库查询时，为了提高查询的性能，我们往往会在表后面加一个nolock，或者是with(nolock)，让数据库在查询时不锁定表，从而提高查询的速度，接下来，通过本篇文章给大家详解sql server 性能优化之nolock，需要的朋友快来学习吧。

 

伴随着时间的增长，公司的数据库会越来越多，查询速度也会越来越慢。打开数据库看到几十万条的数据，查询起来难免不废时间。

　　要提升SQL的查询效能，一般来说大家会以建立索引(index)为第一考虑。其实除了index的建立之外，当我们在下SQL Command时，在语法中加一段WITH (NOLOCK)可以改善在线大量查询的环境中数据集被LOCK的现象藉此改善查询的效能。

　　不过有一点千万要注意的就是，WITH (NOLOCK)的SQL SELECT有可能会造成Dirty Read，就是读到无效的数据。

　　下面对于SQLSERVER的锁争用及nolock,rowlock的原理及使用作一个简单描述：

锁争用的描述

　　那些不仅仅使用行级锁的数据库使用一种称为混和锁(lock escalation)的技术来获取较高的性能。除非很明确知道是针对整个数据表，否则这些数据库的做法是开始使用行级锁， 然后随着修改的数据增多，开始使用大范围的锁机制。

　　不幸的是，这种混和锁的方法会产生和放大新的问题：死锁。如果两个用户以相反的顺序修改位于不同表的记录，而这两条记录虽然逻辑上不相关， 但是物理上是相邻的，操作就会先引发行锁，然后升级为页面锁。这样， 两个用户都需要对方锁定的东西，就造成了死锁。

例如：

　　用户A修改表A的一些记录，引发的页面锁不光锁定正在修改的记录，还会有很多其它记录也会被锁定。

　　用户B修改表B的一些记录，引发的页面锁锁定用户A和其它正在修改的数据。

　　用户A想修改用户B在表B中锁定(并不一定正在修改的)数据。

　　用户B想修改或者仅仅想访问用户A在表A中锁定(并不一定正在修改)的数据。

　　为了解决该问题，数据库会经常去检测是否有死锁存在，如果有，就把其中的一个事务撤销，好让另一个事务能顺利完成。一般来说，都是撤销 那个修改数据量少的事务，这样回滚的开销就比较少。使用行级锁的数据库 很少会有这个问题，因为两个用户同时修改同一条记录的可能性极小，而且由于极其偶然的修改数据的顺序而造成的锁也少。

　　而且，数据库使用锁超时来避免让用户等待时间过长。查询超时的引入也是为了同样目的。我们可以重新递交那些超时的查询，但是这只会造成数据库的堵塞。如果经常发生超时，说明用户使用SQL Server的方式有问题。正常情况是很少会发生超时的。

　　在服务器负载较高的运行环境下，使用混合锁的SQL Server锁机制，表现不会很好。 原因是锁争用(Lock Contention)。锁争用造成死锁和锁等待问题。在一个多用户系统中，很多用户会同时在修改数据库，还有更多的用户在同时访问数据库，随时会产生锁，用户也争先恐后地获取锁以确保自己的操作的正确性，死锁频繁发生，这种情形下，用户的心情可想而知。

　　确实，如果只有少量用户，SQL Server不会遇到多少麻烦。内部测试和发布的时候，由于用户较少，也很难发现那些并发问题。但是当激发几百个并发，进行持续不断地INSERT,UPDATE，以及一些 DELETE操作时，如何观察是否有麻烦出现，那时候你就会手忙脚乱地去解锁。

锁争用的解决方法

　　SQL Server开始是用行级锁的，但是经常会扩大为页面锁和表锁，最终造成死锁。

　　即使用户没有修改数据，SQL Server在SELECT的时候也会遇到锁。幸运的是，我们可以通过SQL Server 的两个关键字来手工处理：NOLOCK和ROWLOCK。

它们的使用方法如下：
 

1. SELECT COUNT(UserID) 
2. 　FROM Users WITH (NOLOCK) 
3. 　WHERE Username LIKE 'football'