说白了,使用的缺点和优点是什么
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
在.NET应用程序和报告服务应用程序的查询中?
说白了,使用的缺点和优点是什么
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
在.NET应用程序和报告服务应用程序的查询中?
当前回答
它的优点是在某些情况下可以更快。缺点是结果可能是错误的(还没有提交的数据可能会返回),并且不能保证结果是可重复的。
如果你在乎准确性,就不要用这个。
更多信息请参阅MSDN:
实现脏读或隔离级别0锁定,这意味着不发布共享锁,也不使用排他锁。当设置此选项时,可以读取未提交或脏数据;在事务结束之前,数据中的值可以更改,数据集中的行可以出现或消失。此选项与在事务中的所有SELECT语句中的所有表上设置NOLOCK具有相同的效果。这是四个隔离级别中限制最少的一个。
其他回答
它可以用于简单的表,例如仅插入的审计表,其中没有对现有行进行更新,也没有对其他表进行fk。插入是一个简单的插入,没有或很少有回滚的机会。
这将为您提供脏读,并显示尚未提交的事务。这是最明显的答案。我不认为仅仅为了加快阅读速度而使用这个方法是个好主意。如果使用良好的数据库设计,还有其他方法可以做到这一点。
注意到没有发生什么也很有趣。READ UNCOMMITTED不仅忽略其他表锁。它自己也不会产生任何锁。
假设您正在生成一个大型报告,或者正在使用一个大型且可能复杂的SELECT语句将数据迁移出数据库。这将导致在事务期间将共享锁升级为共享表锁。其他事务可以从表中读取数据,但是不可能进行更新。如果它是一个生产数据库,这可能是一个坏主意,因为生产可能完全停止。
如果使用READ UNCOMMITTED,则不会在表上设置共享锁。你可以从一些新的事务中获得结果,也可以不从表中插入数据的位置和SELECT事务读取的时间中获得结果。如果发生页面分割,您还可能获得相同的数据两次(数据将被复制到数据文件中的另一个位置)。
因此,如果在执行SELECT操作时可以插入数据对你来说非常重要,READ UNCOMMITTED可能是有意义的。您必须考虑到您的报告可能包含一些错误,但如果它基于数百万行,并且在选择结果时只更新了其中的少数行,那么这可能是“足够好”的。由于不能保证行的唯一性,您的事务也可能一起失败。
更好的方法可能是使用SNAPSHOT ISOLATION LEVEL,但您的应用程序可能需要进行一些调整才能使用它。其中一个例子是,如果您的应用程序对一行采用排他锁以防止其他人读取它,并在UI中进入编辑模式。快照隔离级别也会带来相当大的性能损失(特别是在磁盘上)。但是你可以通过硬件来解决这个问题。:)
您还可以考虑恢复数据库的备份,以用于报告数据或将数据加载到数据仓库中。
关于报告,我们在所有报告查询上使用它,以防止查询陷入数据库。我们可以这样做,因为我们提取的是历史数据,而不是精确到微秒的数据。
它的优点是在某些情况下可以更快。缺点是结果可能是错误的(还没有提交的数据可能会返回),并且不能保证结果是可重复的。
如果你在乎准确性,就不要用这个。
更多信息请参阅MSDN:
实现脏读或隔离级别0锁定,这意味着不发布共享锁,也不使用排他锁。当设置此选项时,可以读取未提交或脏数据;在事务结束之前,数据中的值可以更改,数据集中的行可以出现或消失。此选项与在事务中的所有SELECT语句中的所有表上设置NOLOCK具有相同的效果。这是四个隔离级别中限制最少的一个。
在源不太可能改变的情况下使用READ_UNCOMMITTED。
读取历史数据时。例如,两天前发生的一些部署日志。 再次读取元数据时。例如,基于元数据的应用。
当你知道在获取操作过程中源可能会改变时,不要使用READ_UNCOMMITTED。