一. 基本概念

1.共享鎖：(holdlock)

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

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

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

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

2. 排它鎖：(xlock)

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

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

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

3. 更新鎖：(updlock)

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

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

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

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

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

4. 意向鎖

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

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

　T2：select * from table (tablock)?

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

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

5. 計劃鎖(Schema Locks)

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

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

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

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

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

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

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

注：

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

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

7. rowlock、paglock、tablock 和 holdlock的區(qū)別

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

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

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

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

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

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

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

9.各種鎖的兼容關系

　　

二. 實戰(zhàn)測試

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

?View Code

結論：

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

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

?View Code

結論：

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

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

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

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

?View Code

結論：

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

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

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

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

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

　　證明：

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

　　證明：

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

?View Code

結論：

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

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

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

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

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

?View Code

?結論：

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

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

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

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

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

?View Code

結論：

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

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

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

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

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

?

三. 事務隔離級別

1. 四種錯誤

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

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

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

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

2. 死鎖

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

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

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

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

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

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

　語法：set deadlock_priority <級別>

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

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

(4). 案例測試

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

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

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

1 -- 線程1執(zhí)行下面語句2 begin tran3 begin try4 set deadlock_priority -95 select * from OrderInfor(holdlock) where id='333'6 waitfor delay '0:0:8' --等待8秒執(zhí)行下面的語句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秒執(zhí)行下面的語句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分別執(zhí)行下面語句，產(chǎn)生死鎖，由于線程1設置的級別? -9 < -8，所以線程1犧牲且回滾，最后是線程2執(zhí)行的結果，userName為ypf2? .

?(5). 擴展補充

?A.?查看鎖活動情況

1 select * from sys.dm_tran_locks

B. 查看事務活動情況

1 dbcc opentran

C.? 設置鎖的超時時間

1 set lock_timeout 4000

PS:

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

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

?View Code

?3. 事務隔離級別

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

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

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

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

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

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

線程1執(zhí)行下面代碼：

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

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

情況1

?

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

?

情況2

?

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

?

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

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。