在SELECT语句中使用NOLOCK的目的是什么？

Question

任何人都可以建议在SELECT语句上发出NOLOCK吗？

我正在重新分解一些乱七八糟的存储过程，我理解SELECT语句中的NOLOCK几乎没用。

Answer 1

因此并发数据修改查询不会阻止SELECT。

有些人认为这是一个神奇的快速按钮并且可以自由地应用它。它可能比无用更糟糕，除非你的用例接受读取脏（未提交）数据的可能性，这些数据可能在你阅读之后回滚（因此从不存在逻辑上存在）以及某些类型异常的可能性更大。 / p>

与读取提交的隔离级别nolock相比，扫描丢失数据的可能性更大，读取数据的次数更多，或者数据移动错误完全失败。

Answer 2

我看到一些不良信息已经飞来飞去。选择WITH（NOLOCK）不是在需要速度的任何地方使用的性能工具。阅读此article它会转移到eSamuel提供的答案上，因为是大多数人的想法，正如您可以通过投票看到的那样。那些不知道但反复回忆他们应该怎么做的人。了解如何优化您的数据和查询。 NOLOCK提示应仅用于您始终处理已陷入僵局的记录或NOLOCK为其提供解决方案的其他问题的系统中。

我在一个OLTP系统开发的金融机构工作，该系统每分钟处理大量交易，并为客户和客户提供实时报告功能。这些人整天都在对我们的新数据进行读取，如果我们不使用NOLOCK进行报告查询，那么发生死锁只是时间问题。

进行尽职调查并阅读信誉良好的专业资源，然后再将NOLOCK视为SQL查询速度的圣洁，因为还有更多内容。

Answer 3

NOLOCK相当于交易中的READ-UNCOMMITTED。

简而言之，使用NOLOCK可确保您的SELECT语句快速，因为它不必在返回查询结果之前等待现有锁或事务完成。不利的一面是，您最终可能会撤回“脏”数据 - 这些数据可能在提交之前已经回滚但在运行SELECT语句之后回滚。

其他信息可在Using NOLOCK and READPAST table hints in SQL Server。

中找到

Answer 4

---

如果您从内容很少更改的查找表中读取，NoLocks特别有用。

nolock的问题当然是，如果正在更新表，您可能会得到错误的数据。对于可以正确使用nolock的表格，有些情况会不断更新。例如，你有表：

UserConfig的 {id int PRIMARY KEY，   is_active_flag位，   allow_x_feature位，   allow_y_feature位 }

如果您正在运行选择查询并按ID过滤，那么即使经常更新此表，也要使用nolock。