公司数据库随着时间的增长，数据越来越多，查询速度也越来越慢。进数据库看了一下，几十万调的数据，查询起来确实很费时间。
@H_403_8@ 要提升sql的查询效能，一般来说大家会以建立索引(index)为第一考虑。其实除了index的建立之外，当我们在下sql Command时，在语法中加一段WITH (NolOCK)可以改善在线大量查询的环境中数据集被LOCK的现象藉此改善查询的效能。 @H_403_8@ 不过有一点千万要注意的就是，WITH (NolOCK)的sql SELECT有可能会造成Dirty Read，就是读到无效的数据。 @H_403_8@ 下面对于sqlSERVER的锁争用及nolock,rowlock的原理及使用作一个简单描述： @H_403_8@ 锁争用的描述 @H_403_8@ 那些不仅仅使用行级锁的数据库使用一种称为混和锁(lock escalation)的技术来获取较高的性能。除非很明确知道是针对整个数据表，否则这些数据库的做法是开始使用行级锁， 然后随着修改的数据增多，开始使用大范围的锁机制。 @H_403_8@ 不幸的是，这种混和锁的方法会产生和放大新的问题：死锁。如果两个用户以相反的顺序修改位于不同表的记录，而这两条记录虽然逻辑上不相关， 但是物理上是相邻的， *** 作就会先引发行锁，然后升级为页面锁。这样， 两个用户都需要对方锁定的东西，就造成了死锁。 @H_403_8@ 例如： @H_403_8@ 用户A修改表A的一些记录，引发的页面锁不光锁定正在修改的记录，还会有很多其它记录也会被锁定。 @H_403_8@ 用户B修改表B的一些记录，引发的页面锁锁定用户A和其它正在修改的数据。 @H_403_8@ 用户A想修改用户B在表B中锁定(并不一定正在修改的)数据。 @H_403_8@ 用户B想修改或者仅仅想访问用户A在表A中锁定(并不一定正在修改)的数据。 @H_403_8@ 为了解决该问题，数据库会经常去检测是否有死锁存在，如果有，就把其中的一个事务撤销，好让另一个事务能顺利完成。一般来说，都是撤销 那个修改数据量少的事务，这样回滚的开销就比较少。使用行级锁的数据库 很少会有这个问题，因为两个用户同时修改同一条记录的可能性极小，而且由于极其偶然的修改数据的顺序而造成的锁也少。 @H_403_8@ 而且，数据库使用锁超时来避免让用户等待时间过长。查询超时的引入也是为了同样目的。我们可以重新递交那些超时的查询，但是这只会造成数据库的堵塞。如果经常发生超时，说明用户使用sql Server的方式有问题。正常情况是很少会发生超时的。 @H_403_8@ 在服务器负载较高的运行环境下，使用混合锁的sql Server锁机制，表现不会很好。 原因是锁争用(Lock Contention)。锁争用造成死锁和锁等待问题。在一个多用户系统中，很多用户会同时在修改数据库，还有更多的用户在同时访问数据库，随时会产生锁，用户也争先恐后地获取锁以确保自己的 *** 作的正确性，死锁频繁发生，这种情形下，用户的心情可想而知。 @H_403_8@ 确实，如果只有少量用户，sql Server不会遇到多少麻烦。内部测试和发布的时候，由于用户较少，也很难发现那些并发问题。但是当激发几百个并发，进行持续不断地INSERT,UPDATE，以及一些 DELETE *** 作时，如何观察是否有麻烦出现，那时候你就会手忙脚乱地去解锁。 @H_403_8@ @H_403_8@ 锁争用的解决方法 @H_403_8@ sql Server开始是用行级锁的，但是经常会扩大为页面锁和表锁，最终造成死锁。 @H_403_8@ 即使用户没有修改数据，sql Server在SELECT的时候也会遇到锁。幸运的是，我们可以通过sql Server 的两个关键字来手工处理：NolOCK和ROWLOCK。 @H_403_8@ 它们的使用方法如下： @H_403_8@SELECT COUNT(UserID) FROM Users WITH (NolOCK) WHERE Username liKE 'football'@H_403_8@ 和
UPDATE Users WITH (ROWLOCK)SET Username = 'admin' NolOCK的使用 @H_403_8@ NolOCK可以忽略锁，直接从数据库读取数据。这意味着可以避开锁，从而提高性能和扩展性。但同时也意味着代码出错的可能性存在。你可能会读取到运行事务正在处理的无须验证的未递交数据。 这种风险可以量化。 @H_403_8@ ROWLOCK的使用 @H_403_8@ ROWLOCK告诉sql Server只使用行级锁。ROWLOCK语法可以使用在SELECT,UPDATE和DELETE语句中，不过 我习惯仅仅在UPDATE和DELETE语句中使用。如果在UPDATE语句中有指定的主键，那么就总是会引发行级锁的。但是当sql Server对几个这种UPDATE进行批处理时，某些数据正好在同一个页面(page)，这种情况在当前情况下 是很有可能发生的，这就象在一个目录中，创建文件需要较长的时间，而同时你又在更新这些文件。当页面锁引发后，事情就开始变得糟糕了。而如果在UPDATE或者DELETE时，没有指定主键，数据库当然认为很多数据会收到影响，那样 就会直接引发页面锁，事情同样变得糟糕。 @H_403_8@ 下面写一个例子，来说明一下NolOCK的作用，这里使用一个有一万多条的数据库来测试，先不用NolOCK来看一下： declare @start DATETIME;@end SET @start getdate();select * from Captions_t18;@end select datediff(ms,@start,0); line-height:1.5!important">@end);@H_403_8@ 这里为了是效果更加明显，使用了Select * ，来看一下执行结果，如下图： @H_403_8@ @H_403_8@ 这里显示的使用时间是34720ms,下面使用NolOCK来看一下： from Captions_t18 with (NolOCK); 运行结果如下图： @H_403_8@ @H_403_8@ 这次使用的时间是2563ms，差距体现出来了吧。个人感觉时间不应该差这么多，总之性能是提高了不少。 @H_403_8@ 本文章转自：http://www.cnblogs.com/yunfeifei/p/3848644.HTML 总结
以上是内存溢出为你收集整理的SQLServer性能优化之 nolock，大幅提升数据库查询性能全部内容，希望文章能够帮你解决SQLServer性能优化之 nolock，大幅提升数据库查询性能所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）