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

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

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

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

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

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

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

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

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

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

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

什么时候可以使用READ UNCOMMITTED?

经验法则

好:大的汇总报告显示不断变化的总数。

风险:几乎所有的事情。

好消息是，大多数只读报告都属于“好”类别。

更多细节…

可以使用它:

几乎所有面向用户的当前非静态数据(例如年迄今销售额)汇总报告。 它的误差幅度(可能小于0.1%)远低于其他不确定性因素，如输入错误或只是记录数据的随机时间。

这可能涵盖了商业智能部门在SSRS中所做的大部分工作。当然，任何前面有$符号的东西都是例外。许多人对金钱的热情远远超过了服务客户和产生金钱所需的相关核心指标。(我责怪会计)。

当风险

Any report that goes down to the detail level. If that detail is required it usually implies that every row will be relevant to a decision. In fact, if you can't pull a small subset without blocking it might be for the good reason that it's being currently edited. Historical data. It rarely makes a practical difference but whereas users understand constantly changing data can't be perfect, they don't feel the same about static data. Dirty reads won't hurt here but double reads can occasionally be. Seeing as you shouldn't have blocks on static data anyway, why risk it? Nearly anything that feeds an application which also has write capabilities.

即使是OK场景也不是OK。

是否有应用程序或更新过程使用大型单个事务?那些删除然后重新插入大量你正在报告的记录的?在这种情况下，不能对这些表使用NOLOCK。

它可以用于简单的表，例如仅插入的审计表，其中没有对现有行进行更新，也没有对其他表进行fk。插入是一个简单的插入，没有或很少有回滚的机会。

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

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

更多信息请参阅MSDN:

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