事宜中删除一个记录，再读取此记录，为何还能读到_Sql Server

事务中删除一个记录，再读取此记录，为何还能读到
如T,所有操作都在一个事务中，读取的时候的隔离级别是readUncommited,为什么读出来的记录不是空的。而我在修改了此记录，再读的话，发现数据确实修改了。
------解决方案--------------------

引用:

Quote: 引用:

Quote: 引用:

使用readUncommited可以读到事务中的更改，为什么能读出来已经删除的数据呢？

这个read uncommitted，就是读未提交，既然是未提交，那么就是不确定的状态，可能会读出，也可能不会读出的。

另外，用select * from tb with(nolock) 那么也会导致，有时候读出来的数据更多，有时候读出来的更少。

那这样的话，renUncommited的有什么意义呢？我以为它就是读取事务中已经执行的操作结果，因为这些操作虽然执行，但是没有应用到DB，DB中的还是事务开始前的状态。

read uncommitted这种隔离级别，最多就是应用在查询报表的时候，对数据不需要太准确的地方。

而一般都是采用默认的隔离级别：read committed的。

------解决方案--------------------

引用:

Quote: 引用:

Quote: 引用:

使用readUncommited可以读到事务中的更改，为什么能读出来已经删除的数据呢？

这个read uncommitted，就是读未提交，既然是未提交，那么就是不确定的状态，可能会读出，也可能不会读出的。

另外，用select * from tb with(nolock) 那么也会导致，有时候读出来的数据更多，有时候读出来的更少。

那这样的话，renUncommited的有什么意义呢？我以为它就是读取事务中已经执行的操作结果，因为这些操作虽然执行，但是没有应用到DB，DB中的还是事务开始前的状态。

对于一些对准确性要求不是很严格的查询，为了避免锁的影响，可以考虑使用这种模式，比如我现在公司，有一个报表，需要查询前N天的数据，但是是在活动库上查询，表可能会经常有锁定，为了避免报表的速度，N天前的数据也不需要经常修改，所以这时候可以使用。存在的必然有使用的情景，但是要注意使用情景，不要有就用