任何人都可以提出在SELECT语句上发出NOLOCK的充分理由吗？
我正在重构一些乱七八糟的存储过程，据我了解，SELECT语句上的NOLOCK几乎毫无用处。
因此SELECT，并发不会被并发数据修改查询阻止。
有人认为这是一个神奇的快速按钮，可以自由应用。除非您的用例接受了读取脏的（未提交的）数据的可能性，这些数据可能在您已读取（因此从逻辑上说不存在）后回滚，并且有更大的可能性发生某些类型的异常，否则它会比没用更糟。
与读取提交隔离级别相比nolock，您扫描丢失数据的可能性更高，两次读取或完全由于数据移动错误而失败。
小智 5
我已经看到一些错误的信息了。select上的WITH（NOLOCK）不是在需要速度的地方都可以使用的性能工具。阅读这篇文章它转储由eSamuel提供的答案，因为IS大多数人的想法，因为你可以通过票。那些不知道但反省他们所听到的内容的人应该如何做。首先学习优化数据和查询。NOLOCK提示仅应在持续处理死锁记录或NOLOCK提供解决方案的另一个问题的系统中使用。
我在OLTP系统中开发的金融机构工作，该系统每分钟处理大量交易，并为客户和客户提供实时报告功能。这些人整天都要对我们的新数据进行读取，如果我们不使用NOLOCK进行报告查询，则死锁只是时间问题。
尽一切努力并从信誉良好的专业资料中进行阅读，然后再跳上NOLOCK作为SQL查询速度的神圣方向，因为它还有很多其他功能。