日期:2014-05-17  浏览次数:20504 次

事务中删除一个记录,再读取此记录,为何还能读到
如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天前的数据也不需要经常修改,所以这时候可以使用。存在的必然有使用的情景,但是要注意使用情景,不要有就用