我曾经在一个非常大的组织工作,他们必须NOLOCK在大多数查询中使用- 因为数据通常在白天通过ETL进程更新,并且锁定应用程序40%的工作日当然不是一种选择.
出于习惯,在我的下一个地方,我继续自动使用NOLOCK到处.但是,自从阅读警告和风险以来,我一直在逐步撤消这一点,没有指定任何表提示,让SQL Server做到这一点.
但是,我仍然不舒服我正在做正确的事情.在我们使用的地方NOLOCK,我从来没有看到数据加倍,或数据损坏..我在那里已经很多年了.自从删除以来,NOLOCK我遇到了明显阻碍行阻塞的问题,这些障碍减缓/暂停了查询,从而产生了我的数据库缓慢或松散的错觉.实际上,只是有人在某处运行冗长的保存(他们这样做的能力是应用程序的要求).
我很想听听任何NOLOCK在实践中经历过数据损坏或数据重复的人,而不是那些在互联网上阅读过他们的人.如果有人能提供复制步骤来看到这种情况,我将特别感激.我试图衡量它的风险程度,风险是否超过能够运行与更新平行的报告的明显好处？
我见过NOLOCK的腐败,重复和糟糕的结果.不是一次,也不是很少.依赖于NOLOCK和我有机会查看的每个部署都有正确性问题.确实很多(大多数？)没有意识到并且没有意识到,但问题始终存在.
您必须意识到NOLOCK问题并不表现为硬破坏(DBCC CHECKDB会报告的那种),而是"软"腐败.并且这些问题仅在某些类型的工作负载上很明显,主要是在分析类型(聚合)上.它们会在报告中显示为不正确的值,分类帐中的余额不匹配,错误的部门人数和类似情况.只有经过合格人员的仔细检查,才能将这些问题视为问题.它们可能会在页面的简单刷新上神秘地消失.所以你很可能遇到所有这些问题,而不是意识到它们.您的用户可能会接受"有时余额错误,只需再次询问报告并且可以正常",并且永远不会向您报告问题.
并且有一些工作负载对NOLOCK问题不是很敏感.如果您显示"帖子"和"评论",您将看不到很多NOLOCK问题.也许"未答复的数量"已经过了2,但谁会注意到？
自从删除NOLOCK以来,我遇到了明显阻碍行阻塞减缓/暂停查询的障碍
我建议评估SNPASHOT隔离模型(包括READ_COMMITTED_SNAPSHOT).你可以免费享用午餐.