是否可以在数据库级别设置 no lock 或 TRANSACTION ISOLATION LEVEL READ UNCOMMITTED？答案

【问题标题】：Is it possible to set no lock or TRANSACTION ISOLATION LEVEL READ UNCOMMITTED at database level?是否可以在数据库级别设置 no lock 或 TRANSACTION ISOLATION LEVEL READ UNCOMMITTED？
【发布时间】：2014-11-21 11:16:15
【问题描述】：

在我们的应用程序中，根据 DBA 的建议，我们正在为每个使用的选择查询添加no lock提示。

因此，需要修改每个选择查询以设置表提示，并且需要手动进行。

由于我们想在数据库中的所有表中使用提示，是否可以在 数据库级别这样就不需要修改每个查询并将表提示应用于所有查询？

【问题讨论】：

我会要求您的 dba 证明要求每个 select 语句都应要求无锁定提示，并附上他/她预计会出现问题的真实示例，我会抄送您的经理对话，以确保这样的改变得到他们的认可。 SQL Server 非常擅长在不使用提示的情况下自行处理事情。仅在极少数情况下您可能会考虑使用它们，如果将其批量应用于每个选择查询，我会非常怀疑。
我有兴趣了解推荐背后的原因。
@Tanner，谢谢。我们知道它仅在某些情况下会有所帮助，并且只想知道此类功能是否存在或是否可以解决:)
@NP3，您可以说应用程序用例就像单个用户用例，用户可以添加/修改数据并且他只读取数据。还有其他用户使用相同的表，但数据大多在用户之间隔离。因此，在这种特殊情况下，用户可能会从中受益
如果真的是不同用户几乎不会读取相同数据的情况，根本不需要提示，甚至快照隔离也可能是矫枉过正。 SQL Server 完全能够在适当的情况下在行级别锁定数据，因此不涉及彼此数据的查询根本不会相互阻塞。我真的希望你的 DBA 也知道这些事情......

标签： sql sql-server sql-server-2008

【解决方案1】：

简短的回答是“不”。 SQL Server 中的默认隔离级别是READ COMMITTED，无法将其更改为UNCOMMITTED，无论是全局还是每个数据库。这也是一件非常好的事情。

WITH (NOLOCK) 是从数据库中获取准确结果的麻烦，在糟糕的情况下，它甚至可能导致由于数据移动而永远运行的查询超时（NOLOCK 无法防止） .请参阅Is the NOLOCK (Sql Server hint) bad practice? 了解更多讨论，以及一些关于替代方案的好技巧。

特别是，许多需要大量阅读器并希望在不阻塞的情况下继续运行的应用程序可以从快照隔离中受益。与UNCOMMITTED 不同，您可以使用READ_COMMITTED_SNAPSHOT 选项将快照隔离设置为默认设置。在执行此操作之前，请务必阅读快照隔离的优缺点 - 或者更好的是，请您的 DBA 执行此操作，因为任何建议全局使用 WITH (NOLOCK) 的 DBA 都有一些阅读要做。查询提示只能作为最后的手段使用。

【讨论】：

谢谢，您已经很好地解释了您的答案。我将探索更多关于快照隔离的知识，并在本地系统的示例数据库中使用它，然后决定它是否有助于这种情况