一. 基本概念

1.共享鎖：(holdlock)

　(1). select的時候會自動加上共享鎖，該條語句執行完，共享鎖立即釋放，與事務是否提交沒有關系。

　(2). 顯式通過添加(holdlock)來顯式添加共享鎖（比如給select語句顯式添加共享鎖），當在事務里的時候，需要事務結束，該共享鎖才能釋放。

　(3). 同一資源，共享鎖和排它鎖不能共存，意味著update之前必須等資源上的共享鎖釋放后才能進行。

　(4). 共享鎖和共享鎖可以共存在一個資源上，意味著同一個資源允許多個線程同時進行select。

2. 排它鎖：(xlock)

　(1). update(或 insert 或 delete)的時候加自動加上排它鎖，該條語句執行完，排它鎖立即釋放，如果有事務的話，需要事務提交，該排它鎖才能釋放。

　(2). 顯式的通過添加(xlock)來顯式的添加排它鎖（比如給select語句顯式添加排它鎖），如果有事務的話，需要事務提交，該排它鎖才能釋放。

　(2). 同一資源，共享鎖和排它鎖不能共存，意味著update之前必須等資源上的共享鎖釋放后才能進行。

3. 更新鎖：(updlock)

　(1). 更新鎖只能顯式的通過(updlock)來添加，當在事務里的時候，需要事務結束，該更新鎖才能釋放。

　(2). 共享鎖和更新鎖可以同時在同一個資源上，即加了更新鎖，其他線程仍然可以進行select。

　(3).?更新鎖和更新鎖不能共存(同一時間同一資源上不能存在兩個更新鎖)。

　(4).?更新鎖和排它鎖不兼容。

　(5). 利用更新鎖來解決死鎖問題，要比xlock性能高一些，因為加了updlock后，其他線程是可以進行select的。

4. 意向鎖

　意向鎖分為三種：意向共享 (IS)、意向排他 (IX) 和意向排他共享 (SIX)。?意向鎖可以提高性能，因為數據庫引擎僅在表級檢查意向鎖來確定事務是否可以安全地獲取該表上的鎖，而不需要檢查表中的每行或每頁上的鎖以確定事務是否可以鎖定整個表.

　T1：select * from table (xlock) where id=10

　T2：select * from table (tablock)?

分析：T1線程執行該語句時，會對該表id=10的這一行加排他鎖，同時會對整個表加上意向排它鎖(IX)，當T2執行的時候，不需要逐條去檢查資源，只需要看到該表已經存在【意向排它鎖】，就直接等待。

PS： update table set xx=xx where id=1， 不光會對id=1的這條記錄加排它鎖，還會對整張表加意向排它鎖。

5. 計劃鎖(Schema Locks)

　用jdbc向數據庫發送了一條新的sql語句，數據庫要先對之進行編譯，在編譯期間，也會加鎖，稱之為：計劃鎖。

　編譯這條語句過程中，其它線程可以對表做任何操作(update、delete、加排他鎖等等），但不能做DDL(比如alter table)操作。

6. 鎖的顆粒：行鎖、頁鎖、表鎖

　(1). rowlock：行鎖---對每一行加鎖，然后釋放。(對某行加共享鎖)

　(2). paglock：頁鎖---1執行時，會先對第一頁加鎖，讀完第一頁后，釋放鎖，再對第二頁加鎖，依此類推。(對某頁加共享鎖)

　　假設前10行記錄恰好是一頁(當然，一般不可能一頁只有10行記錄），那么T1執行到第一頁查詢時，并不會阻塞T2的更新。

　(3). tablock：表鎖---對整個表加鎖，然后釋放。?(對整張表加共享鎖)

注：

　　1. 以上三種鎖執行完該語句后即可釋放，無須等待事務的提交，與事務是否提交沒有關系。

　　2. 以上三種鎖劃分的角度不同，都是共享鎖，所以他們相互之間是可以共存的。

7. rowlock、paglock、tablock 和 holdlock的區別

　二者無非是劃分的角度不同，其實都是共享鎖，但在釋放上有所不同

　tablock（rowlock、paglock）：對表、行、頁加共享鎖，只要語句執行完，就釋放，與事務是否提交沒關系。

　holdlock：對表加共享鎖，必須等著事務執行完，才能釋放。

8. tablockx對表加排它鎖，在有事務和沒事務的時候的區別

　(1). 無事務的時候：其他線程無法對該表進行讀和更新，除非加tablockx的語句執行完，才能進行。

　(2). 有事務的時候：必須整個事務執行了commit或rollback后才會釋放該排他鎖。

　xlock還可這么用：select * from table(xlock tablock) 效果等同于select * from table(tablockx)

9.各種鎖的兼容關系

　　

二. 實戰測試

1. 測試共享鎖和共享鎖可以共存

?View Code

結論：

　　默認加 或者 顯式(holdlock)的方式加，都能共存。

2. 測試排它鎖和排它鎖不能共存

?View Code

結論：

　　1. 關于排它鎖，無論是顯式(xlock)模式添加還是update默認加的模式，如果在事務里都需要事務提交才能釋放。

　　2. 默認與默認、顯式與顯式、默認與顯式 這三種組合關系都不能共存，所以證明排它鎖和排它鎖之間不能共存。

　　3. 注意：這里加排他鎖，會在表層次上加上意向排它鎖，與操作那條數據無關。

3. 測試共享鎖和排它鎖不能共存(顯式和隱式) （兩個結論未完成）

?View Code

結論：

　　1.默認select共享鎖先執行,未提交事務的情況下，默認update排它鎖 和 顯式排它鎖(xlock)都能正常執行。，

　　證明：默認共享鎖語句執行完立即釋放，與事務是否提交沒有關系

　　2.顯式共享鎖(holdlock),未提交事務的情況下,默認update排它鎖 和 顯式排它鎖(xlock)都 不能 正常執行，

　　證明：顯式共享鎖(holdlock)需要事務提交才能釋放，同時也證明共享鎖和排它鎖不能共存。

　　3.默認update排它鎖先執行，未提交事務的情況下，默認select共享鎖能執行，顯式共享鎖(holdlock)不能執行。

　　證明：

　　4.顯式排它鎖(xlock)先執行，未提交事務的情況下，默認select共享鎖能執行，顯式共享鎖(holdlock)不能執行。

　　證明：

4. 測試共享鎖、更新鎖、排它鎖間的關系

?View Code

結論：

　　1. 更新鎖需要事務提交才能釋放。

　　2. 更新鎖和更新鎖不能共存。

　　3. 更新鎖和排它鎖不能共存。

　　4. 更新鎖和共享鎖可以共存。

5. 測試表鎖和排它鎖不能共存

?View Code

?結論：

　　1. 先執行表鎖，事務未提交的情況下，排它鎖能正常進行。

　　證明：表鎖只要執行完該語句立即釋放，與事務是否提交沒有關系。

　　2. 先執行默認排它鎖，事務未提交的情況想，表鎖不能運行。

　　證明：默認的排它鎖必須等待事務提交完才能釋放，同時證明排它鎖和表鎖不能共存 （表鎖在這里的特點和共享鎖一樣，實質表鎖也就是個共享鎖，只是劃分的角度不同）

6. 測試行鎖和排它鎖不能共存

?View Code

結論：

　　1. 先執行行鎖，事務未提交的情況下，排它鎖能正常進行。

　　證明：行鎖只要執行完該語句立即釋放，與事務是否提交沒有關系。

　　2. 先執行默認排它鎖，事務未提交的情況想，行鎖不能運行。

　　證明：默認的排它鎖必須等待事務提交完才能釋放，同時證明排它鎖和行鎖不能共存 （行鎖在這里的特點和共享鎖一樣，實質表鎖也就是個共享鎖，只是劃分的角度不同）。

7. 測試頁鎖和排它鎖不能共存(與表鎖、行鎖類似，不單獨測試)

?

三. 事務隔離級別

1. 四種錯誤

　(1). 臟讀：第一個事務讀取第二個事務正在更新的數據，如果第二個事務還沒有更新完成，那么第一個事務讀取的數據將是一半為更新過的，一半還沒更新過的數據，這樣的數據毫無意義。

　(2). 幻讀：第一個事務讀取一個結果集后，第二個事務，對這個結果集進行“增刪”操作，然而第一個事務中再次對這個結果集進行查詢時，數據發現丟失或新增。

　(3).?更新丟失：多個用戶同時對一個數據資源進行更新，必定會產生被覆蓋的數據，造成數據讀寫異常。

　(4). 不可重復讀：如果一個用戶在一個事務中多次讀取一條數據，而另外一個用戶則同時更新啦這條數據，造成第一個用戶多次讀取數據不一致。

2. 死鎖

(1). 定義：相互等待對方釋放資源，造成資源讀寫擁擠堵塞的情況，就被稱為死鎖現象，也叫做阻塞。如下面的例子：

1 begin tran 2 select * from OrderInfor(holdlock) where id='333' 3 waitfor delay '0:0:8' --等待8秒執行下面的語句 4 update OrderInfor set userName='ypf1' where id='333' 5 commit tran

分析：線程T1 和 線程T2 同時執行該事務，假設線程T1先執行完select，線程T2隨后執行完select，線程T1要執行update語句的時候，根據數據庫策略需要將【共享鎖】提升為【排它鎖】才能執行，所以必須等線程T2上的【共享鎖】釋放，而線程T2需要事務提交完才能釋放鎖，同時T1的【共享鎖】不釋放導致T2要一直等待，這樣造成了T1和T2相互等待的局面，就是死鎖現象。

(2).?數據庫的默認處理思路的邏輯：

　　數據庫并不會出現無限等待的情況，是因為數據庫搜索引擎會定期檢測這種狀況，一旦發現有情況，立馬【隨機】選擇一個事務作為犧牲品。犧牲的事務，將會回滾數據。有點像兩個人在過獨木橋，兩個無腦的人都走在啦獨木橋中間，如果不落水，必定要有一個人給退回來。這種相互等待的過程，是一種耗時耗資源的現象，所以能避則避。

(3). 手動控制鎖級別：

　語法：set deadlock_priority <級別>

　死鎖處理的優先級別為 low<normal<high，不指定的情況下默認為normal，犧牲品為隨機。如果指定，犧牲品為級別低的。

　還可以使用數字來處理標識級別：-10到-5為low，-5為normal，-5到10為high，數越小，級別越低，越先犧牲，越先回滾。

(4). 案例測試

　　事先準備：?使用【LockDemoDB】中的OrderInfor表進行測試，?事先插入一條測試數據，之后都使用該數據進行測試。

1 insert into OrderInfor values('333','ypf','去青島','lmr','1')

　　在兩個窗口里（即兩個線程）執行下面一段代碼：

1 -- 線程1執行下面語句2 begin tran3 begin try4 set deadlock_priority -95 select * from OrderInfor(holdlock) where id='333'6 waitfor delay '0:0:8' --等待8秒執行下面的語句7 update OrderInfor set userName='ypf1' where id='333'8 commit tran9 end try 10 begin catch 11 rollback tran 12 end catch

1 -- 線程2測試(下面語句單獨開一個窗口進行測試)2 begin tran3 begin try4 set deadlock_priority -85 select * from OrderInfor(holdlock) where id='333'6 waitfor delay '0:0:8' --等待8秒執行下面的語句7 update OrderInfor set userName='ypf2' where id='333'8 commit tran9 end try 10 begin catch 11 rollback tran 12 end catch

分析：線程1和線程2分別執行下面語句，產生死鎖，由于線程1設置的級別? -9 < -8，所以線程1犧牲且回滾，最后是線程2執行的結果，userName為ypf2? .

?(5). 擴展補充

?A.?查看鎖活動情況

1 select * from sys.dm_tran_locks

B. 查看事務活動情況

1 dbcc opentran

C.? 設置鎖的超時時間

1 set lock_timeout 4000

PS:

　　?發生死鎖的時候，數據庫引擎會自動檢測死鎖，解決問題，然而這樣子是很被動，只能在發生死鎖后，等待處理。然而我們也可以主動出擊，設置鎖超時時間，一旦資源被鎖定阻塞，超過設置的鎖定時間，阻塞語句自動取消，釋放資源，報1222錯誤。

　　好東西一般都具有兩面性，調優的同時，也有他的不足之處，那就是一旦超過時間，語句取消，釋放資源，但是當前報錯事務，不會回滾，會造成數據錯誤，你需要在程序中捕獲1222錯誤，用程序處理當前事務的邏輯，使數據正確。為0時，即為一旦發現資源鎖定，立即報錯，不在等待，當前事務不回滾，設置時間需謹慎處理后事啊，你hold不住的。
拓展殺死鎖和進程

?View Code

?3. 事務隔離級別

　　read uncommitted：這個隔離級別最低啦，可以讀取到一個事務正在處理的數據，但事務還未提交，這種級別的讀取叫做臟讀。

　　read committed：這個級別是默認選項，不能臟讀，不能讀取事務正在處理沒有提交的數據，但能修改。

　　repeatable read：不能讀取事務正在處理的數據，也不能修改事務處理數據前的數據。

　　snapshot：指定事務在開始的時候，就獲得了已經提交數據的快照，因此當前事務只能看到事務開始之前對數據所做的修改。

　　serializable：最高事務隔離級別，只能看到事務處理之前的數據。?

?事先準備：?使用【LockDemoDB】中的OrderInfor表進行測試，?事先插入一條測試數據，之后都使用該數據進行測試。

線程1執行下面代碼：

1 begin tran 2 update OrderInfor set userName='ypf1' where id='333' 3 waitfor delay '0:0:8' --等待8秒執行下面的語句 4 rollback tran

?線程1執行后，開啟一個新線程（在一個新窗口）馬上執行下面代碼：

情況1

?

1 --1. 設置允許臟讀，能馬上讀出來數據 2 set tran isolation level read uncommitted 3 select * from OrderInfor where id='333' --讀取的數據為正在修改的數據 ，即為臟讀 4 5 --8秒之后數據已經回滾,查出來的數據是回滾后的數據 ypf 6 waitfor delay '0:0:8' 7 select * from OrderInfor where id='333'

?

情況2

?

1 --2. 設置不允許臟讀，不能馬上讀出來數據（數據庫默認就是這種模式） 2 set tran isolation level read committed 3 select * from OrderInfor where id='333' 4 5 6 --可以修改(但也得等線程1執行完事務后),8s后顯示的是 ypf2，而不是原回滾后的數據ypf 7 update OrderInfor set userName='ypf2' where id='333' 8 waitfor delay '0:0:8' 9 select * from OrderInfor where id='333'

?

其它三種暫不測試了，與此同樣道理進行測試。

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的第八节：数据库层次的锁机制详解和事务隔离级别的全部內容，希望文章能夠幫你解決所遇到的問題。

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