SQL Server事務的隔離級別

########## 數據庫中數據的一致性 ##########

針對并發事務出現的數據不一致性，提出了4個級別的解決方法：

?隔離級別	?第一類丟失更新	?臟讀	不可重復讀	?第二類丟失更新	?虛讀
?未提交讀	?未發生	?發生	?發生	?發生	?發生
?提交讀	?未發生	?未發生	?發生	?發生	?發生
?可重復讀	?未發生	?未發生	?未發生	?未發生	?發生
?串行化	?未發生	?未發生	?未發生	?未發生	?未發生

???

1.未提交讀

采用排它鎖(update, insert, delete)，解決了丟失更新問題，但是臟讀仍然會出現。

例1：

begin tran

update t1 set t1.name = 'yyy'

waitfor delay '00:00:10' --等待10秒

rollback tran

例2：

set transaction isolation level read uncommitted

begin tran

select * from t1

commit tran

結果：例2返回更新后的值(yyy)，盡管最后更新回滾了。

?

2.提交讀

采用共享鎖(select)+排它鎖(update, insert, delete)，解決了丟失更新問題，也解決了臟讀問題。SQL Server默認屬于這個隔離級別。

?

3.可重復讀

采用修改鎖(update)+排它鎖(insert, delete)+共享鎖(select)，解決了丟失更新問題，臟讀問題，但是會出現幻像讀。

例3：

set transaction isolation level repeatable read

begin tran

select * from t1

waitfor delay '00:00:10'

select * from t1

commit tran

例4：

set transaction isolation level repeatable read

begin tran

delete from t1 where t1.id = 8

commit tran

結果：例3，2次返回的結果集都一樣，都含有t1.id=8的行。

?

4.可串行讀

采用一個事務執行完后，才能執行第2個事務（被阻塞）的串行方式，解決了以上所有的問題。

例5：

set transaction isolation level serializable

begin tran

select * from t1

waitfor delay '00:00:10'

commit tran

例6：

set transaction isolation level serializable

begin tran

delete from t1 where t1.id = 9

commit tran

結果：例5，2次都返回一樣的結果，是刪除前的。只能說明實現了可重復讀級別的事務。

例7：

set transaction isolation level serializable

begin tran

select * from t1

waitfor delay '00:00:10'

select * from t1

commit tran

例8：

set transaction isolation level serializable

begin tran

insert into t1(name) values('zhang')

commit tran

結果：例7，2次都返回一樣的結果，都是添加前的結果集。結合前面的例子說明是串行級別。

轉載于:https://www.cnblogs.com/wuxiang/p/3656171.html

總結

以上是生活随笔為你收集整理的SQL Server事务的隔离级别的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。