在源不太可能改变的情况下使用READ_UNCOMMITTED。

读取历史数据时。例如，两天前发生的一些部署日志。 再次读取元数据时。例如，基于元数据的应用。

当你知道在获取操作过程中源可能会改变时，不要使用READ_UNCOMMITTED。

我最喜欢的read uncommitted用例是调试事务中发生的一些事情。

在调试器下启动软件，当您逐步执行代码行时，它会打开一个事务并修改数据库。当代码停止时，您可以打开一个查询分析器，将其设置为读取未提交隔离级别，并进行查询以查看发生了什么。

您还可以使用它来查看长时间运行的过程是否卡住，或者使用带有count(*)的查询正确地更新数据库。

如果您的公司喜欢创建过于复杂的存储过程，那么这是很好的选择。

关于报告，我们在所有报告查询上使用它，以防止查询陷入数据库。我们可以这样做，因为我们提取的是历史数据，而不是精确到微秒的数据。

它的优点是在某些情况下可以更快。缺点是结果可能是错误的(还没有提交的数据可能会返回)，并且不能保证结果是可重复的。

如果你在乎准确性，就不要用这个。

更多信息请参阅MSDN:

实现脏读或隔离级别0锁定，这意味着不发布共享锁，也不使用排他锁。当设置此选项时，可以读取未提交或脏数据;在事务结束之前，数据中的值可以更改，数据集中的行可以出现或消失。此选项与在事务中的所有SELECT语句中的所有表上设置NOLOCK具有相同的效果。这是四个隔离级别中限制最少的一个。

在源不太可能改变的情况下使用READ_UNCOMMITTED。

读取历史数据时。例如，两天前发生的一些部署日志。 再次读取元数据时。例如，基于元数据的应用。

当你知道在获取操作过程中源可能会改变时，不要使用READ_UNCOMMITTED。

此隔离级别允许脏读。一个事务可以看到其他事务所做的未提交的更改。

为了保持最高级别的隔离，DBMS通常需要对数据进行锁定，这可能会导致并发性损失和较高的锁定开销。此隔离级别将放松此属性。

你可能想要查看维基百科上关于READ UNCOMMITTED的文章，以获得一些例子和进一步的阅读。

您可能还会对Jeff Atwood的博客文章感兴趣，这篇文章讲述了他和他的团队在Stack Overflow早期是如何解决死锁问题的。杰夫说:

But is nolock dangerous? Could you end up reading invalid data with read uncommitted on? Yes, in theory. You'll find no shortage of database architecture astronauts who start dropping ACID science on you and all but pull the building fire alarm when you tell them you want to try nolock. It's true: the theory is scary. But here's what I think: "In theory there is no difference between theory and practice. In practice there is." I would never recommend using nolock as a general "good for what ails you" snake oil fix for any database deadlocking problems you may have. You should try to diagnose the source of the problem first. But in practice adding nolock to queries that you absolutely know are simple, straightforward read-only affairs never seems to lead to problems... As long as you know what you're doing.

您可能想要考虑的READ UNCOMMITTED级别的一个替代方案是READ COMMITTED SNAPSHOT。再次引用杰夫的话:

快照依赖于一种全新的数据变化跟踪方法…不仅仅是轻微的逻辑更改，它还要求服务器以不同的物理方式处理数据。一旦启用了这个新的数据更改跟踪方法，它就会为每个数据更改创建一个副本或快照。通过在争用时读取这些快照而不是实时数据，读取时不再需要共享锁，并且整体数据库性能可能会提高。