SQL SERVER的鎖機制

SQL SERVER的鎖機制（一）——概述（鎖的種類與範圍）

SQL SERVER的鎖機制（二）——概述（鎖的兼容性與能夠鎖定的資源）

SQL SERVER的鎖機制（三）——概述（鎖與事務隔離級別）

SQL SERVER的鎖機制（四）——概述（各類事務隔離級別發生的影響）

 

 

SQL SERVER的鎖機制（一）——概述（鎖的種類與範圍）

鎖定：通俗的講就是加鎖。鎖定是 Microsoft SQL Server 數據庫引擎用來同步多個用戶同時對同一個數據塊的訪問的一種機制。

定義：當有事務操做時，數據庫引擎會要求不一樣類型的鎖定，如相關數據行、數據頁或是整個數據表，當鎖定運行時，會阻止其餘事務對已經鎖定的數據行、數據頁或數據表進行操做。只有在當前事務對於本身鎖定的資源不在須要時，纔會釋放其鎖定的資源，供其餘事務使用。

1、鎖的種類與範圍（以下表）

鎖類型	說明
共享 (S)	用於不更改或不更新數據的讀取操做，如 SELECT 語句。
更新 (U)	用於可更新的資源中。 防止當多個會話在讀取、鎖定以及隨後可能進行的資源更新時發生常見形式的死鎖。
獨佔(也可稱排他)(X)	用於數據修改操做，例如 INSERT、UPDATE 或 DELETE。 確保不會同時對同一資源進行多重更新。
意向	用於創建鎖的層次結構。 意向鎖包含三種類型：意向共享 (IS)、意向排他 (IX) 和意向排他共享 (SIX)。
架構	在執行依賴於表架構的操做時使用。 架構鎖包含兩種類型：架構修改 (Sch-M) 和架構穩定性 (Sch-S)。
大容量更新 (BU)	在向表進行大容量數據複製且指定了 TABLOCK 提示時使用。
鍵範圍	當使用可序列化事務隔離級別時保護查詢讀取的行的範圍。 確保再次運行查詢時其餘事務沒法插入符合可序列化事務的查詢的行。

 

 

（一）共享鎖

共享鎖（S 鎖）容許併發事務在封閉式併發控制下讀取 (SELECT) 資源。 

當查詢（SELECT）某條記錄時，SQL SERVER 會嘗試取得該條記錄的上存在共享鎖（S 鎖），或沒法獲取，就必須等待別人釋放對該記錄中某幾種與共享鎖互斥的鎖，才能在設置共享鎖以後，獲取該條記錄。

舉例來講：當某人查詢某張表的一條記錄時，就會在該記錄上放置共享鎖，在而其餘人也要查詢這張表的此記錄時，由於共享鎖彼此不互斥，因此也能夠再次放置共享鎖，也就是說SQL SERVER容許不一樣鏈接同時讀取相同的數據。若是此時有人要更新此記錄，由於獨佔鎖與共享鎖互斥，因此沒法放置獨佔鎖，要等到全部讀取此記錄的人都讀取完畢，釋放了共享鎖，更新數據的人才能對該記錄設置獨佔鎖，並進一步更新數據。通常狀況下，在默認的事務隔離級別下，當數據讀取完畢，SQL SERVER就會釋放共享鎖，除非有特別的設置。

 

（二）更新鎖

更新鎖是一種中繼鎖。當同一項資源從原來的查詢操做轉換爲更新操做時，鎖定機制會從共享鎖變爲更新鎖，再進一步變成獨佔鎖。

在可重複讀或可序列化事務中，此事務讀取數據 [獲取資源（頁或行）的共享鎖（S 鎖）]，而後修改數據 [此操做要求鎖轉換爲獨佔鎖（X 鎖）]。 若是兩個事務得到了資源上的共享模式鎖，而後試圖同時更新數據，則一個事務嘗試將鎖轉換爲獨佔鎖（X 鎖）。 共享模式到獨佔鎖的轉換必須等待一段時間，由於一個事務的獨佔鎖與其餘事務的共享模式鎖不兼容；發生鎖等待。 第二個事務試圖獲取獨佔鎖（X 鎖）以進行更新。 因爲兩個事務都要轉換爲獨佔鎖（X 鎖），而且每一個事務都等待另外一個事務釋放共享模式鎖，所以發生死鎖。

若要避免這種潛在的死鎖問題，請使用更新鎖（U 鎖）。 一次只有一個事務能夠得到資源的更新鎖（U 鎖）。 若是事務修改資源，則更新鎖（U 鎖）轉換爲獨佔鎖（X 鎖）。

例如，當查詢一條記錄後，要將此內容更新（Update語句加上Where條件），必定會先查找記錄，在查找的過程當中就會對相關的記錄放置共享鎖，等找到相應的記錄以後，SQL SERVER 會先對記錄放置更新鎖，以免發生死鎖。由於共享鎖與更新鎖並不互斥，若是兩我的同時對同一條記錄放置共享鎖，先進行更新的人，能夠在別人也對同一條記錄放置了共享鎖時，繼續放置更新鎖，但由於更新鎖互斥，因此當另外一我的想再放置更新鎖時，將沒法設置，而進入中止等待狀態。

 

（三）獨佔鎖（也可稱爲排他鎖）

獨佔鎖(排他鎖)（X 鎖）能夠防止併發事務對資源進行訪問。 使用獨佔鎖（X 鎖）時，任何其餘事務都沒法修改數據；僅在使用 NOLOCK 提示或未提交讀隔離級別時纔會進行讀取操做。

對數據進行添加、修改、刪除操做時（如 INSERT、UPDATE 和 DELETE）， 語句在執行所需的操做以前首先執行讀取操做以獲取數據。 所以，需先對所在的資源放置獨佔鎖，以確保以上操做未完成時，不受到干擾，獨佔鎖在開啓事務以後，一直保留到事務結束。例如，UPDATE 語句可能根據與一個表的聯接修改另外一個表中的行。 在此狀況下，除了請求更新行上的獨佔鎖以外，UPDATE 語句還將請求在聯接表中讀取的行上的共享鎖。

（四）意向鎖

在記錄上放置共享鎖以前，須要對存放該記錄的更大範圍（如數據頁或數據表）上設置意向鎖，以免其餘鏈接對該頁放置獨佔鎖。

數據庫引擎使用意向鎖來保護共享鎖（S 鎖）或獨佔鎖（X 鎖）放置在鎖層次結構的底層資源上。 意向鎖之因此命名爲意向鎖，是由於在較低級別鎖前可獲取它們，所以會通知意向將鎖放置在較低級別上。

意向鎖有兩種用途：

· 防止其餘事務以會使較低級別的鎖無效的方式修改較高級別資源。

· 提升數據庫引擎在較高的粒度級別檢測鎖衝突的效率。

例如，在該表的數據頁或數據行上請求共享鎖（S 鎖）以前，在表級(或頁級)請求共享意向鎖，以防止另外一個事務隨後在包含那一頁的表上嘗試放置獨佔鎖（X 鎖）。 意向鎖能夠提升性能，由於數據庫引擎僅在表級檢查意向鎖來肯定事務是否能夠安全地獲取該表上的鎖。 而不須要檢查表中的每行或每頁上的鎖以肯定事務是否能夠鎖定整個表。以下圖。

 

意向鎖包括意向共享 (IS)、意向排他 (IX) 以及意向排他共享 (SIX)等等。各類意向鎖的說明，以下表。

鎖類型	說明
意向共享 (IS)	保護針對層次結構中某些（而並不是全部）低層資源請求或獲取的共享鎖。
意向獨佔 (IX)	保護針對層次結構中某些（而並不是全部）低層資源請求或獲取的獨佔鎖。 IX 是 IS 的超集，它也保護針對低層級別資源請求的共享鎖。
意向獨佔共享 (SIX)	保護針對層次結構中某些（而並不是全部）低層資源請求或獲取的共享鎖以及針對某些（而並不是全部）低層資源請求或獲取的意向獨佔鎖。 頂級資源容許使用併發 IS 鎖。 例如，獲取表上的 SIX 鎖也將獲取正在修改的頁上的意向獨佔鎖以及修改的行上的獨佔鎖。 雖然每一個資源在一段時間內只能有一個 SIX 鎖，以防止其餘事務對資源進行更新，可是其餘事務能夠經過獲取表級的 IS 鎖來讀取層次結構中的低層資源。
意向更新 (IU)	保護針對層次結構中全部低層資源請求或獲取的更新鎖。 僅在頁資源上使用 IU 鎖。 若是進行了更新操做，IU 鎖將轉換爲 IX 鎖。
共享意向更新 (SIU)	S 鎖和 IU 鎖的組合，做爲分別獲取這些鎖而且同時持有兩種鎖的結果。 例如，事務執行帶有 PAGLOCK 提示的查詢，而後執行更新操做。 帶有 PAGLOCK 提示的查詢將獲取 S 鎖，更新操做將獲取 IU 鎖。
更新意向排他 (UIX)	U 鎖和 IX 鎖的組合，做爲分別獲取這些鎖而且同時持有兩種鎖的結果。

 

下面來實際舉例來講明

 

--示例代碼一：

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ

BEGIN TRAN

SELECT * FROM [Book] WHERE [bookid]=1

WAITFOR DELAY '00:00:10'

COMMIT TRAN

 

 

 

能夠經過另外一條鏈接執行SP_LOCK 來查看上面代碼的執行結果，以下圖。在數據表上與數據頁上都放置了意向共享鎖，而在鎖定的記錄上放置了共享鎖。

 

 

 

--示例代碼二：

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ

BEGIN TRAN

SELECT * FROM [WBK_PDE_LIST] WHERE [WBOOK_NO]='BE404942450020' and cop_g_no='60217445'

WAITFOR DELAY '00:00:10'

COMMIT TRAN

 

 

 

能夠經過另外一條鏈接執行SP_LOCK 來查看上面代碼的執行結果，以下圖。因爲上述代碼中的[WBK_PDE_LIST]是一張堆表，因此直接就對數據表加了共享鎖。

 

對上述示例中表WBK_PDE_LIST添加索引，

 

CREATE NONCLUSTERED INDEX [IX_WBK_PDE_LIST_WBOOKNO] ON [dbo].[WBK_PDE_LIST] 

(

[WBOOK_NO] ASC,

[COP_G_NO] ASC

)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF

, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]

GO

 

 

 

而後再次執行代碼示例二，再打開一個新的查詢分析器，在查詢分析器中執行SP_LOCK 來查看上面代碼的執行結果，以下圖。在數據表與數據頁上分別放置了意向共享鎖，在索引與數據行上放置了共享鎖。

 

（五）架構鎖

數據庫引擎在表數據定義語言 (DDL) 操做（例如添加列或刪除表）的過程當中使用架構修改 (Sch-M) 鎖。 保持該鎖期間，Sch-M 鎖將阻止對錶進行併發訪問。 這意味着 Sch-M 鎖在釋放前將阻止全部外圍操做。

某些數據操做語言 (DML) 操做（例如表截斷）使用 Sch-M 鎖阻止併發操做訪問受影響的表。

數據庫引擎在編譯和執行查詢時使用架構穩定性 (Sch-S) 鎖。 Sch-S 鎖不會阻止某些事務鎖，其中包括排他 (X) 鎖。 所以，在編譯查詢的過程當中，其餘事務（包括那些針對表使用 X 鎖的事務）將繼續運行。 可是，沒法針對表執行獲取 Sch-M 鎖的併發 DDL 操做和併發 DML 操做。

（六）大容量更新鎖

數據庫引擎在將數據大容量複製到表中時，指定 TABLOCK 提示或使用 sp_tableoption 選項（將數據表設置爲 table lock on bulk load），則是使用大容量更新鎖（BU）。 大容量更新鎖（BU 鎖）容許多個線程將數據併發地大容量加載到同一表，以下降數據表的鎖定競爭，同時防止其餘不進行大容量加載數據的進程訪問該表。

（七）鍵範圍鎖

在使用可序列化事務隔離級別時，保護用戶對於查詢時所讀取的數據行範圍，以確保其餘事務沒法插入受「鍵範圍鎖」保護的數據行。鍵範圍鎖放置在索引上，指定開始與結束的索引鍵值。這些操做會先在索引上獲取鎖定，此種鎖定能夠封鎖任未嘗試進行插入、修改、刪除索引鍵值在「鍵範圍鎖」中的數據行。例如：在索引鍵值「AAA」至「CZZ」範圍中放置鍵範圍鎖，避免其餘事務將含有索引鍵值的數據行插入到該範圍內的任何地方，例如：「ABC」、「BCD」、「CEF」。另外當UPDATE語句搭配WHERE子句時，當SQL SERVER還在查找數據時，也有可能會設置鍵範圍鎖。

 

 

SQL SERVER的鎖機制（二）——概述（鎖的兼容性與能夠鎖定的資源）

 

2、完整的鎖兼容性矩陣(見下圖)

 

 對上圖的是代碼說明：見下圖。

 

3、下表列出了數據庫引擎能夠鎖定的資源。

名稱	資源	縮寫	編碼	呈現鎖定時，描述該資源的方式	說明
數據行	RID	RID	9	文件編號：分頁編號：Slot編號	用於鎖定堆中的單個行的行標識符。
索引鍵	KEY	KEY	7	6字節哈希值	索引中用於保護可序列化事務中的鍵範圍的行鎖。
分頁	PAGE	PAG	6	文件編號：分頁編號	數據庫中的 8 KB 頁，例如數據頁或索引頁。
範圍	EXTENT	EXT	8	文件編號：範圍的第一個分頁的編號	一組連續的八頁，例如數據頁或索引頁。
	HoBT				堆或 B 樹。 用於保護沒有彙集索引的表中的 B 樹（索引）或堆數據頁的鎖。
數據表	TABLE	TAB	5	數據表ID（OBJID字段）	包括全部數據和索引的整個表。
文件	FILE	FIL	3	文件編號	數據庫文件。
應用程序	APPLICATION	APP	10	6字節哈希值	應用程序專用的資源。
	METADATA				元數據鎖。
	ALLOCATION_UNIT				分配單元。
數據庫	DATABASE	DB	2	數據庫代碼（DBID字段）	整個數據庫。
索引		IDX	4	Db_id:object_id:index_id相關的其餘資源	索引中的數據行鎖定，

 

 

 

 

4、SQL SERVER要鎖定資源時，默認是從最底級開始鎖起，例如，索引鍵值，數據行，以免大範圍鎖定，以免影響其餘人同時訪問該範圍內的其餘數據，可是當內存不足時，SQL SERVER會自動擴大鎖定範圍以減低管理鎖定的負荷。下面咱們來看一個示例。

 

 

--創建SP_LOCK輸出緩存表

if exists( select * from tempdb..sysobjects where name like '#temp%' and type ='u')

begin

drop table #temp

create table #temp(spid int,dbid int ,objid int,indid int,type varchar(3),resource varchar(20)

,mode varchar(20),status varchar(5))

end

begin tran

update WBK_PDE_head set [COP_EMS_NO]='abcde' where wbook_no='BE404942850177'

insert #temp exec sp_lock @@spid

commit tran

 

-----獲取dbid

--select DB_ID('Test')

--只查看定製的數據庫的相關資源,sql 2008

select spid,數據庫=DB_NAME(dbid),對象=OBJECT_NAME(objid),

索引=(select name from sysindexes where ID=OBJID and indid=t.indid ),

TYPE,resource,mode,status from #temp t where dbid=28

order by dbid,objid,indid

---

---以SQL 2005的sys.indexes表查詢相關數據

 

select spid,數據庫=DB_NAME(dbid),對象=OBJECT_NAME(objid),

索引=(select name from sys.indexes where object_id=OBJID and index_id=t.indid ),

TYPE,resource,mode,status from #temp t where dbid=28

order by dbid,objid,indid

 

 

說明：

1.創建臨時表#Temp用以存儲系統存儲過程sp_lock輸出的數據

2.開啓事務，而後更新數據(update)，但不去確認事務，數據庫會鎖定相關對象，將sp_lock所呈現的相關數據插入到#Temp表中，並將結果查詢出來。

 

在查詢分析器中執行如下代碼

 

select a.*,b.name from #temp a left join sysobjects b on a.objid=b.id 

order by a.type

 

圖以下示:

 

 

 

SQL SERVER的鎖機制（三）——概述（鎖與事務隔離級別）

 

5、鎖與事務隔離級別

事務隔離級別簡單的說，就是當激活事務時，控制事務內因SQL語句產生的鎖定須要保留多入，影響範圍多大，以防止多人訪問時，在事務內發生數據查詢的錯誤。設置事務隔離級別將影響整條鏈接。

SQL Server 數據庫引擎支持全部這些隔離級別：

· 未提交讀（隔離事務的最低級別，只能保證不讀取物理上損壞的數據）

· 已提交讀（數據庫引擎的默認級別）

· 可重複讀

· 可序列化（隔離事務的最高級別，事務之間徹底隔離）

SQL Server 還支持使用行版本控制的兩個事務隔離級別。一個是已提交讀隔離的新實現，另外一個是新事務隔離級別（快照）。

 

設置語句以下：

SET TRANSACTION ISOLATION LEVEL     { READ UNCOMMITTED     | READ COMMITTED     | REPEATABLE READ     | SNAPSHOT     | SERIALIZABLE     } [ ; ]

 

（一）未提交讀

未提交讀是最低的事務隔離級別，容許讀取其餘事務已經修改但未提交的數據行。SQL SERVER 當此事務等級進行嘗試讀取數據時，不會放置共享鎖，直接讀取數據，因此忽略已存在的互斥鎖。換句話說，即便該資源已經受到了獨佔鎖的保護，當使用未提交讀隔離級別時，此數據仍是能夠被讀取，加快查詢速度，可是會讀取到別人未修改的數據，因此此種讀取被稱爲髒讀。此種隔離級別適合不在意數據變動的查詢場景。此隔離級別與SELECT 語句搭配 NOLOCK 所起到的效果相同

未提交讀示例：

--1.--1.建立測試表

create table tbUnRead

(ID INT,

name nvarchar(20)

)

--2新增記錄

insert tbUnRead 

select 1,'Tom'

union

select 2,'Jack'

--3開啓事務，並進行更新

 

begin tran

update tbUnRead

set name='Jack_upd'

where ID=2

---4查詢事務數量(因爲沒有回滾或提交事務)

SELECT @@TRANCOUNT

事務查詢結果以下：

 

--5打開另外一條鏈接，設置事務隔離級別爲(未提交讀)

set Transaction isolation level read uncommitted

--6查詢數據，查詢到的數據是修改以後的數據。

select * from tbUnRead where ID=2

以下圖：

 

 

（二）已提交讀

已提交讀是SQL SERVER 默認的事務隔離級別。當事務正在讀取數據時，SQL SERVER 會放置共享鎖以防止其餘事務修改數據，當數據讀取完成以後，會自動釋放共享鎖，其餘事務能夠進行數據修改。由於共享鎖會同時封鎖封鎖語句執行，因此在事務完成數據修改以前，是沒法讀取該事務正在修改的數據行。所以此隔離級別能夠防止髒讀。

 

在SQL SERVER 2005以上版本中，若是設置READ_COMMITTED_SNAPSHOT爲ON，則已提交讀的事務全使用數據行版本控制的隔離下讀取數據。讀取操做不會獲取正被讀取的數據上的共享鎖（S 鎖），所以不會阻塞正在修改數據的事務。同時，因爲減小了所獲取的鎖的數量，所以最大程度地下降了鎖定資源的開銷。使用行版本控制的已提交讀隔離和快照隔離旨在提供副本數據的語句級或事務級讀取一致性。

示例一：設置READ_COMMITTED_SNAPSHOT爲OFF

--1.建立測試表

create table tbUnRead

(ID INT,

name nvarchar(20)

)

--2新增記錄

insert tbUnRead 

select 1,'Tom'

union

select 2,'Jack'

--3開啓事務，並進行更新

 

begin tran

update tbUnRead

set name='Jack_upd'

where ID=2

---4查詢事務數量(因爲沒有回滾或提交事務)

SELECT @@TRANCOUNT

--5打開另外一條鏈接，設置事務隔離級別爲(已提交讀)

set Transaction isolation level read committed

--6查詢數據，因爲當前事務沒有提交，因此沒法查詢數據

select * from tbUnRead where ID=2

6查詢數據的結果 以下圖：

 

 

 

示例二：設置READ_COMMITTED_SNAPSHOT爲ON

use master

go

---建立測試數據庫

create database read_committed_SNAPSHOT_Test

go

---激活數據行版本控制

alter database read_committed_SNAPSHOT_Test  set read_committed_SNAPSHOT on

go

 

use read_committed_SNAPSHOT_Test

go

 

--1.建立測試表

create table tbReadLevel

(ID INT,

name nvarchar(20)

)

 

--2新增記錄

insert tbReadLevel

select 1,'測試'

go

select ID,name as "修改前數據"  from tbReadLevel

以下圖：

 

go

--3開啓事務，並進行更新

 

begin tran

update tbReadLevel

set name='Jack_upd'

where ID=1

---4查詢事務數量(因爲沒有回滾或提交事務)

SELECT @@TRANCOUNT

 

--5打開另外一條鏈接，設置事務隔離級別爲(已提交讀)

--查詢數據，查詢到的數據是上一次提交的數據

select * from tbReadLevel where ID=1

 5的查詢結果以下圖：

 

（三）可重複讀

可重複讀事務隔離級別在事務過程當中，全部的共享鎖均保留到事務結束，而不是讀取結束就釋放，這與已提交讀的行爲大相徑庭，雖然在事務過程當中，重複查詢相同記錄時不受其餘事務的影響，但可能因爲鎖定數據太久，而致使其餘人沒法處理數據，影響併發率，更嚴重的可能提升發生死鎖的機率。

  總之，若是使用可重複讀隔離級別讀取數據，數據讀出以後，其餘事務只能對此範圍中的數據進行讀取或新增，但不能夠進行修改，直到讀取事務完成。所以，使用此隔離級別須要謹慎當心，根據實際狀況進行設置。

 

示例：

 

--1.建立測試表

create table tbUnRead

(ID INT,

name nvarchar(20)

)

--2新增記錄

insert tbUnRead 

select 1,'Tom'

union

select 2,'Jack'

 

--3設置事務隔離級別爲(可重複讀)

set Transaction isolation level REPEATABLE READ

--4開啓事務，並進行更新

begin tran

 

--5查詢數據

select * from tbUnRead where ID=2

---6查詢事務數量(沒有回滾或提交事務)

SELECT @@TRANCOUNT

5與6的執行結果以下圖

 

---7開啓另外一條鏈接，查詢數據與修改數據 

---事務雖然沒有完成，但能夠查詢到以前的數據

select * from tbUnRead where ID=2

Go

---8，修改數據，因爲事務沒有完成，因此沒法進行修改

update tbUnRead

set name='Jack_upd'

where ID=2

go

--七、8的執行結果以下，能夠查詢數據，但沒法更新數據，以下圖。

 

 

 

（四）快照

快照隔離級別是SQL SERVER 2005以後版本新增的隔離級別，開啓以後，容許事務過程當中讀取操做不受異動影響，事務中任一語句所讀取的數據，均予事務激活時，就已經完成提交，符合事務一致性的數據行版本。因此只能查覈事務激活以前已經完成提交的數據，也就是說能夠查詢已經完成提交的數據行快照集，但看不見已激活的事務正在進行修改的數據行。當使用快照隔離級別讀取數據時不會要求對數據進行鎖定，若是所讀取的記錄正在被某事務進行修改，它也會讀取此記錄以前已經提交的數據。故當某記錄被事務進行修改時，SQL SERVER的TEMPDB數據庫會存儲最近提交的數據行，以供快照隔離級別的事務讀取數據時使用。將Allow_SNAPSHOT_isolation設爲ON，事務就會設置快照隔離級別。

 

use master

go

---建立測試數據庫(快照)

create database SNAPSHOT_Test

go

---激活數據行版本控制

alter database SNAPSHOT_Test  set Allow_SNAPSHOT_isolation on

go

 

use SNAPSHOT_Test

go

 

--1.建立測試表

create table tbReadLevel

(ID INT,

name nvarchar(20)

)

 

--2新增記錄

insert tbReadLevel

select 1,'測試'

union

select 2,'快照測試'

go

select ID,name as "修改前數據"

from tbReadLevel

go

--3開啓事務，並進行更新

begin tran

update tbReadLevel

set name='Jack_upd_快照'

where ID=1

---4查詢事務數量(沒有回滾或提交事務)

SELECT @@TRANCOUNT

--二、4的執行結果，以下圖。

 

--5打開另外一條鏈接，設置事務隔離級別爲(快照)

set Transaction isolation level SNAPSHOT

--6查詢數據，查詢的數據是上一次提交的數據

select * from tbReadLevel where ID=1

 

 

（五）可序列化

可序列化是事務隔離級別中最高的級別，爲最嚴謹的隔離級別，由於它會鎖定整個範圍的索引鍵，使事務與其餘事務徹底隔離。在現行事務完成以前，其餘事務不能插入新的數據行，其索引鍵值存在於現行事務所讀取的索引鍵範圍之中。此隔離級別與Select 搭配holdlock效果同樣。

示例：

--1.建立測試表

create table tbUnRead

(ID INT,

name nvarchar(20)

)

--2新增記錄

insert tbUnRead 

select 1,'Tom'

union

select 2,'Jack'

--3設置事務隔離級別爲(可序列化)

 

set Transaction isolation level SERIALIZABLE

--5開啓事務，並進行更新

begin tran

select * from tbUnRead where ID=2

---6查詢事務數量(沒有回滾或提交事務)

SELECT @@TRANCOUNT

五、6執行結果以下圖。

---7，開啓另外一條鏈接，查詢數據，能夠查詢到以前的數據

select * from tbUnRead where ID=2

---8，修改數據，沒法修改數據

update tbUnRead

set name='Jack_upd'

where ID=2

--新增數據，沒法插入數據

insert tbUnRead 

select 3,'May'

 

 

SQL SERVER的鎖機制（四）——概述（各類事務隔離級別發生的影響）

6、各類事務隔離級別發生的影響

修改數據的用戶會影響同時讀取或修改相同數據的其餘用戶。即這些用戶能夠併發訪問數據。若是數據存儲系統沒有併發控制，則用戶可能會看到如下負面影響：

· 未提交的依賴關係（髒讀）

· 不一致的分析（不可重複讀）

· 幻讀

（一）髒讀：

例：張某正在執行某項業務，以下：

 

begin tran

insert tbUnRead 

select 3,'張三'

union

select 4,'李四'

---延遲秒，模擬真實交易情形，用於處理業務邏輯

waitfor delay '00:00:05'

rollback tran

---此時李某對錶中數據進行查詢，執行了如下語句：

set Transaction isolation level read uncommitted

--查詢數據

select * from tbUnRead where name like '張%'

 

 

 

則李某能夠看到張某所執行的插入語句，把數據添加到了數據庫，以下圖。

可是張某最終是沒有提交事務，而是回滾了事務，因此這條記錄並無真正插入到數據庫中。從而發生李某將髒讀的數據當成真實的查詢結果。

   要解決此問題，就是要把數據庫的事務隔離級別由未提交讀修改爲已提交讀。只有當查詢結果的正確性不是很是重要，或者是隔一段時間查詢一次狀況下，即便這一次查詢結果是錯，而下次查詢結果是對的，並不會有太大影響，這才適合使用未提交讀。

 

（二）不可重複讀

例：張某正在查詢數據，以下

 

set Transaction isolation level read committed

begin tran

select * from tbUnRead  where ID=2

 

---延遲秒，模擬真實交易情形，用於處理業務邏輯

waitfor delay '00:00:05'

select * from tbUnRead  where ID=2

 

commit tran

---此時李對錶中數據進行了更新，以下語句：

update tbUnRead

set name='Jack_upd'

where ID=2

 

 

 上面的執行語句形成張某在同一個事務內，兩次相同的查詢條件，查詢到不相同的結果（以下圖）。

這是因爲「已提交讀」隔離級別對共享鎖保留的時間是：一旦查詢完畢就當即釋放，而非事務完成才釋放。所在張某雖然還在使用事務，事務過程當中的全部獨佔鎖都會一直保留，讓事務中所更改的數據別人不可進行查詢與更改，直到事務完成。可是，被查詢的數據在事務過程當中是查詢完畢就當即釋放共享鎖，因此別人仍然能夠進行修改，形成一筆事務中，兩次相同的查詢條件，能夠獲得不相同的結果。最佳的解決方案是將隔離級別設置爲「可重複讀」。

「可重複讀」事務隔離級別，讓事務過程當中所曾經創建的共享鎖都一直保留到事務完成，雖然能夠避免「不可重複讀」的問題，可是也會致使數據鎖定過久，而別人沒法讀取數據，影響併發率，甚至提升了「死鎖」的發生率。

 

（三）幻讀

例：張某正在查詢數據，以下

 

set Transaction isolation level REPEATABLE READ

begin tran

select * from tbUnRead  where ID=3

 

---延遲秒，模擬真實交易情形，用於處理業務邏輯

waitfor delay '00:00:05'

select * from tbUnRead  where ID=3

 

commit tran

 

--此時李某新增了一條記錄，以下語句：

INSERT TBUNread

select 3,'幻讀'

 

 

 

 

張某已經把隔離級別設置爲「可重複讀」，雖然是曾經讀取的數據，無論是共享鎖仍是互斥鎖都 保留到了事務結束，可是沒法阻止其餘人運行新增操做，致使第一次查詢時沒有數據，第二次查詢時卻有了數據。被稱爲「幻讀」。以下圖。

爲了不此類問題，能夠將隔離級別設置爲「可序列化」，設置以後，則其餘人則沒法新增數據。

 

 

7、各隔離級別所能防止的訪問錯誤

隔離級別	髒讀	不可重複讀	幻讀
未提交讀	是	是	是
已提交讀	否	是	是
可重複讀	否	否	是
快照	否	否	否
可序列化	否	否	否

 

 

8、經常使用鎖與事務隔離級別間的交互影響

	已提交讀	可重複讀	快照	可序列化
共享	讀完數據後就釋放	事務結束才釋放	不加鎖，以版原本控制	事務結束才釋放
更新	讀完數據後就釋放或是升級成獨佔鎖	讀完數據後就釋放或是升級成獨佔鎖	不加鎖，以版原本控制	讀完數據後就釋放或升級成獨佔鎖
獨佔	事務結束才釋放	事務結束才釋放	不加鎖，以版原本控制	事務結束才釋放

 

9、動態鎖定管理

數據庫引擎使用動態鎖定管理策略來控制鎖定和系統的最佳成本效益。數據庫引擎能夠動態調整數據粒度與鎖定類型，當使用最低一級的行鎖而非更大範圍的頁鎖時，能夠下降兩個事務要求相同範圍的數據鎖定的可能性，加強並行訪問的能力，可同時服務更多的用戶，減少死鎖的機率。相反低級鎖轉爲高級鎖能夠減少系統的資源負擔，但會增長並行爭用的可能性。

此機制由鎖管理器進行管理，每個鎖都須要內存去記錄，而且要與鎖管理器進行合做，才能完成數據訪問操做，你能夠想像當表中有100萬條記錄時，你執行一條沒有where語句的update指令時，在默認狀況下數據庫引擎會採用行鎖，但這要記錄100萬條行鎖記錄，以及相關的意向共享鎖，一定會消耗掉大量的系統資源，當系統資源不足時，數據庫引擎會自動提高鎖的級別，也就是由行鎖提高爲頁鎖，若是資源仍是不足，則會再次提高，提高爲表鎖。

就以上例子來講，若是每一個頁能夠放200條記錄，則100萬表記錄的行鎖轉爲5000個頁鎖，還省掉了大量的意向共享鎖。若是資源仍是一足，則能夠再次提高鎖級別，提高到表鎖，這樣就只須要一個鎖就能夠了。

愈大範圍的鎖花費在管理鎖之上的資源就愈少。但相對來講，同時上線併發訪問該資源的人數就越少。例如：或採用行鎖，則你訪問你的記錄，我訪問個人記錄，互相不影響，但若是升級到頁鎖，則若是你先搶到該分頁，而我要訪問的記錄又偏偏在這一分頁上，則我必需要等你釋放該分頁以後才能訪問。若是升級到表鎖，則同一時間，該表中的記錄只能一我的才能訪問，其餘人不能訪問。以下圖。

 

 

 

通常狀況下，是不須要手工去設置鎖定範圍的，能夠由Microsoft SQL Server 數據庫引擎視狀況而定，使用動態鎖定策略肯定最經濟的鎖。 執行查詢時，數據庫引擎會根據架構和查詢的特色自動決定最合適的鎖。 例如，爲了縮減鎖定的開銷，優化器可能在執行索引掃描時在索引中選擇頁級鎖。

動態鎖定具備下列優勢：

· 簡化數據庫管理。 數據庫管理員沒必要調整鎖升級閾值。

· 提升性能。 數據庫引擎經過使用適合任務的鎖使系統開銷減至最小。

· 應用程序開發人員能夠集中精力進行開發。 數據庫引擎將自動調整鎖定。

在 SQL Server 2008 中，鎖升級的行爲已發生改變，其中引入了 LOCK_ESCALATION選項