我现在总是使用READ UNCOMMITTED。速度快，问题少。当使用其他隔离时，你几乎总是会遇到一些阻塞问题。

只要你使用自动递增字段，多注意一下插入，你就可以和阻塞问题说再见了。

你可以用READ uncommitted犯错误，但老实说，确保你的插入是完全证明是很容易的。使用选择结果的插入/更新只是你需要注意的事情。(此处使用READ COMMITTED，或确保脏读不会引起问题)

所以去脏读吧(特别是大报告)，你的软件会运行得更流畅……

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

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

更多信息请参阅MSDN:

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

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

什么时候可以使用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。

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

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

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

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

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