Bri*_*ler 9 sql deadlock nolock sql-server-2005
我有一些长时间运行的查询不时出现超时问题和死锁.
我想知道什么时候最适合使用NOLOCK而在哪里？
我是否在更新和插入中使用它？还是读？
请注意,您可以基于每个表指定nolock.
我通常在复杂的SELECT查询中使用nolock,但仅用于几乎从不更改的小查找表,以及仅显示数据.您知道列出当前半年价格的表格,或者查找字符串的ID等等.只有主要更新才会发生变化,之后通常会重新启动服务器.
这显着提高了性能,减少了在最繁忙时间发生死锁的可能性,更重要的是,在最糟糕的情况下,触及大量表的查询(这是合乎逻辑的,他们必须获得更少的锁,以及那些副表)真的很明显经常在几乎所有地方使用,通常从需要锁定的7-8个表减少到4个表
但是要非常小心地添加它,不要急于它,并且不要经常这样做.如果使用得当,它不会受到伤害,但如果使用不当会伤害到它.
不要将它用于高度关键的东西,计算等的东西,因为它会变得不一致,迟早会导致写入的任何东西.
另一个这样的优化是ROWLOCK,它只锁定在行级别上.这在更新(或删除)行彼此无关的表时非常有用,例如只放入日志记录的表(以及插入它们的顺序无关紧要).如果你有一个方案,在事务结束的某个地方,日志记录写入某个表,这也会大大加快.
如果您的数据库写入百分比相对较低,则可能不值得.我的读:写比率低于2:1.
我在处理这个时保存的一些网址:
http://www.developerfusion.com/article/1688/sql-server-locks/4/
SQL Server中有四个事务隔离级别:
对于它所应用的表,NOLOCK相当于"read uncommitted".这意味着您可以查看将来可能会回滚的事务中的行,以及许多其他奇怪的结果.
不过,nolock在实践中表现很好.特别是对于只读查询,显示略有错误的数据不是世界末日,如业务报告.我会在更新或插入附近,或通常在决策代码附近的任何地方避免它,特别是如果它涉及发票.
作为nolock的替代方案,请考虑"读取提交的快照",这适用于具有大量读取和较少写入活动的数据库.你可以用以下方式打开它:
ALTER DATABASE YourDb SET READ_COMMITTED_SNAPSHOT ON;
它适用于SQL Server 2005及更高版本.这就是Oracle默认工作的方式,也就是stackoverflow本身使用的方式.甚至还有关于它的编码恐怖博客文章.
PS长时间运行的查询和死锁也可能表明SQL Server正在使用错误的假设.检查您的统计信息或索引是否已过期:
SELECT
object_name = Object_Name(ind.object_id),
IndexName = ind.name,
StatisticsDate = STATS_DATE(ind.object_id, ind.index_id)
FROM SYS.INDEXES ind
order by STATS_DATE(ind.object_id, ind.index_id) desc
统计数据应在每周维护计划中更新.
使用 nolock 作为最后的手段。大多数死锁问题可以通过调整查询和/或调整索引来解决。我想我在过去 5 年里见过一个僵局，而且无法通过调整两者之一来解决。
另请注意，NOLOCK 仅适用于 select 语句。数据修改将始终锁定，该行为无法更改。因此，如果遇到写入器/写入器死锁（很常见），那么没有锁根本没有帮助。
另请注意，nolock 除了返回脏数据之外，还可能导致重复行（从基础表中读取两次的行）和丢失行（基础表中根本未读取的行）。
Nolock 本质上对 SQL Server 意味着“我不介意我的结果是否稍微不准确”
快照隔离是一种选择。只需确保您首先仔细测试，因为 TempDB 上的负载增加可能会非常严重，具体取决于事务的频率和持续时间。另请注意，虽然您不会在快照隔离中看到死锁，但可能会出现更新冲突。再次测试并确保您的应用程序正常工作并且可以处理出现的任何错误。