大家好,请问下。SQLSERVER 默认的隔离级别是?
如果有个事务还没结束,但是已经更新了某个值。这时有用户更好查询该条记录,请问我读到是改前的值还是改后的值如下:
begin tranupdate area set AreaName='交易所99'  where AreaTId=1waitfor delay '00:00:15'commit tran
--------------------------------------------------------
select * from area with (nolock)  where AreaTId=1那么AreaName读到是原来的值,还是 '交易所99'的值sqlserver事务

解决方案 »

  1.   

    默认是read committed。如果有个事务还没结束,但是已经更新了某个值。这时有用户更好查询该条记录,请问我读到是改前的值还是改后的值
    会等待,除非用了with nolock
      

  2.   

    请问下。SQLSERVER 默认的隔离级别是?
    --> read committed (读取已提交)--> AreaName读到是"交易所99".
      

  3.   

    with(nolock)会读到已修改但未提交的数据,这就是传说中的“脏读”
      

  4.   

    事务隔离级别 .
    SQL Server通过在锁资源上使用不同类型的锁来隔离事务。为了开发安全的事务,定义事务内容以及应在何种情况下回滚至关重要,定义如何以及在多长时间内在事务中保持锁定也同等重要。这由隔离级别决定。应用不同的隔离级别,SQL Server赋予开发者一种能力,让他们为每一个单独事务定义与其他事务的隔离程度。事务隔离级别的定义如下:
    •是否在读数据的时候使用锁 
    •读锁持续多长时间 
    •在读数据的时候使用何种类型的锁 
    •读操作希望读已经被其他事务排他锁住的数据时,怎么办?在这种情况下,SQL Server可以: 
    ◦一直等到其他事务释放锁 
    ◦读没有提交的数据 
    ◦读数据最后提交后的版本 
    ANSI 99定义了4种事务隔离级别,SQL Server 2005能够完全支持这些级别:
    •未提交读 在读数据时不会检查或使用任何锁。因此,在这种隔离级别中可能读取到没有提交的数据。
    •已提交读 只读取提交的数据并等待其他事务释放排他锁。读数据的共享锁在读操作完成后立即释放。已提交读是SQL Server的默认隔离级别。
    •可重复读 像已提交读级别那样读数据,但会保持共享锁直到事务结束。
    •可序列化 工作方式类似于可重复读。但它不仅会锁定受影响的数据,还会锁定这个范围。这就阻止了新数据插入查询所涉及的范围,这种情况可以导致幻像读。
    此外,SQL Server还有两种使用行版本控制来读取数据的事务级别(本章后文将详细检验这些隔离级别)。行版本控制允许一个事务在数据排他锁定后读取数据的最后提交版本。由于不必等待到锁释放就可进行读操作,因此查询性能得以大大增强。这两种隔离级别如下:
    •已提交读快照 它是一种提交读级别的新实现。不像一般的提交读级别,SQL Server会读取最后提交的版本并因此不必在进行读操作时等待直到锁被释放。这个级别可以替代提交读级别。
    •快照 这种隔离使用行版本来提供事务级别的读取一致性。这意味着在一个事务中,由于读一致性可以通过行版本控制实现,因此同样的数据总是可以像在可序列化级别上一样被读取而不必为防止来自其他事务的更改而被锁定。
     
    无论定义什么隔离级别,对数据的更改总是通过排他锁来锁定并直到事务结束时才释放。
    很多情况下,定义正确的隔离级别并不是一个简单的决定。作为一种通用的规则,要选择在尽可能短的时间内锁住最少数据,但同时依然可以为事务提供它所需的安全程度的隔离级别
     SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED  --未提交读
    SET TRANSACTION ISOLATION LEVEL READ COMMITTED    --已提交读
    SET TRANSACTION ISOLATION LEVEL REPEATABLE READ   --获取一致的可重复读操作 
    SET TRANSACTION ISOLATION LEVEL SNAPSHOT          --已提交读快照级
    SET TRANSACTION ISOLATION LEVEL SERIALIZABLE      --系列化级别
    --更多
    http://blog.csdn.net/hdhai9451/article/details/11028589