一. 基本概念

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. 測試共享鎖和共享鎖可以共存

1 {2 Console.WriteLine("測試共享鎖和共享鎖可以共存");3 Console.WriteLine("共享鎖select默認添加：1, 共享鎖(holdlock)顯式添加：2");4 string num = Console.ReadLine();5 if (num == "1")6 {7 using (LockDemoDBEntities1 db = new LockDemoDBEntities1())8 using (var tx = db.Database.BeginTransaction())9 { 10 Console.WriteLine("開始查詢"); 11 //select的時候會加共享鎖 12 var orderInfor = db.Database.SqlQuery<OrderInfor>("select * from OrderInfor where id=2").FirstOrDefault(); 13 Console.WriteLine($"id為：{orderInfor.id},userName為：{orderInfor.userName},destination為：{orderInfor.destination}"); 14 15 Console.WriteLine("按任意鍵進行事務提交"); 16 Console.ReadKey(); 17 try 18 { 19 tx.Commit(); 20 Console.WriteLine("事務提交成功"); 21 } 22 catch (Exception ex) 23 { 24 tx.Rollback(); 25 Console.WriteLine("事務提交失敗"); 26 Console.WriteLine(ex.Message); 27 } 28 } 29 } 30 else if (num == "2") 31 { 32 using (LockDemoDBEntities1 db = new LockDemoDBEntities1()) 33 using (var tx = db.Database.BeginTransaction()) 34 { 35 Console.WriteLine("開始查詢"); 36 //顯式的通過holdlock添加 37 var orderInfor = db.Database.SqlQuery<OrderInfor>("select * from OrderInfor(holdlock) where id=2").FirstOrDefault(); 38 Console.WriteLine($"id為：{orderInfor.id},userName為：{orderInfor.userName},destination為：{orderInfor.destination}"); 39 40 Console.WriteLine("按任意鍵進行事務提交"); 41 Console.ReadKey(); 42 try 43 { 44 tx.Commit(); 45 Console.WriteLine("事務提交成功"); 46 } 47 catch (Exception ex) 48 { 49 tx.Rollback(); 50 Console.WriteLine("事務提交失敗"); 51 Console.WriteLine(ex.Message); 52 } 53 } 54 } 55 }

結論：

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

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

1 {2 Console.WriteLine("測試排它鎖和排它鎖不能共存");3 Console.WriteLine("排它鎖update默認添加：1, 排它鎖(xlock)顯式添加：2");4 string num = Console.ReadLine();5 if (num == "1")6 {7 Console.WriteLine("排它鎖業務");8 using (LockDemoDBEntities1 db = new LockDemoDBEntities1())9 using (var tx = db.Database.BeginTransaction()) 10 { 11 Console.WriteLine("開始更新"); 12 //update的時候會自動加排它鎖 13 var result = db.Database.ExecuteSqlCommand("update OrderInfor set userName='lmr2' where id=2"); 14 Console.WriteLine("按任意鍵進行事務提交"); 15 Console.ReadKey(); 16 try 17 { 18 tx.Commit(); 19 Console.WriteLine("事務提交成功"); 20 } 21 catch (Exception ex) 22 { 23 tx.Rollback(); 24 Console.WriteLine("事務提交失敗"); 25 Console.WriteLine(ex.Message); 26 } 27 } 28 29 } 30 else if (num == "2") 31 { 32 using (LockDemoDBEntities1 db = new LockDemoDBEntities1()) 33 using (var tx = db.Database.BeginTransaction()) 34 { 35 Console.WriteLine("開始查詢"); 36 //select的時候會對id=1的那行加上排它鎖，同時對整張表加上意向排它鎖，當別的線程查詢該表時，不用逐條去檢查資源 37 //只需要看到該表存在【意向排它鎖】，就會等待，無論查詢id等于幾，都會等待 38 var orderInfor = db.Database.SqlQuery<OrderInfor>("select * from OrderInfor (xlock) where id=1").FirstOrDefault(); 39 Console.WriteLine($"id為：{orderInfor.id},userName為：{orderInfor.userName},destination為：{orderInfor.destination}"); 40 41 Console.WriteLine("按任意鍵進行事務提交"); 42 Console.ReadKey(); 43 try 44 { 45 tx.Commit(); 46 Console.WriteLine("事務提交成功"); 47 } 48 catch (Exception ex) 49 { 50 tx.Rollback(); 51 Console.WriteLine("事務提交失敗"); 52 Console.WriteLine(ex.Message); 53 } 54 } 55 } 56 57 }

結論：

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

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

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

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

1 {2 Console.WriteLine("測試排它鎖和排它鎖不能共存");3 Console.WriteLine("默認select共享鎖：1, 顯式共享鎖(holdlock)：2,默認update排它鎖：3，顯式排它鎖(xlock)：4");4 string num = Console.ReadLine();5 6 if (num == "1")7 {8 using (LockDemoDBEntities1 db = new LockDemoDBEntities1())9 using (var tx = db.Database.BeginTransaction())10 {11 Console.WriteLine("開始查詢");12 //select的時候會加共享鎖13 var orderInfor = db.Database.SqlQuery<OrderInfor>("select * from OrderInfor where id=2").FirstOrDefault();14 Console.WriteLine($"id為：{orderInfor.id},userName為：{orderInfor.userName},destination為：{orderInfor.destination}");15 16 Console.WriteLine("按任意鍵進行事務提交");17 Console.ReadKey();18 try19 {20 tx.Commit();21 Console.WriteLine("事務提交成功");22 }23 catch (Exception ex)24 {25 tx.Rollback();26 Console.WriteLine("事務提交失敗");27 Console.WriteLine(ex.Message);28 }29 }30 }31 else if (num == "2")32 {33 using (LockDemoDBEntities1 db = new LockDemoDBEntities1())34 using (var tx = db.Database.BeginTransaction())35 {36 Console.WriteLine("開始查詢");37 //顯式的通過holdlock添加38 var orderInfor = db.Database.SqlQuery<OrderInfor>("select * from OrderInfor(holdlock) where id=2").FirstOrDefault();39 Console.WriteLine($"id為：{orderInfor.id},userName為：{orderInfor.userName},destination為：{orderInfor.destination}");40 41 Console.WriteLine("按任意鍵進行事務提交");42 Console.ReadKey();43 try44 {45 tx.Commit();46 Console.WriteLine("事務提交成功");47 }48 catch (Exception ex)49 {50 tx.Rollback();51 Console.WriteLine("事務提交失敗");52 Console.WriteLine(ex.Message);53 }54 }55 }56 else if (num == "3")57 {58 using (LockDemoDBEntities1 db = new LockDemoDBEntities1())59 using (var tx = db.Database.BeginTransaction())60 {61 Console.WriteLine("開始更新");62 //update的時候會自動加排它鎖63 var result = db.Database.ExecuteSqlCommand("update OrderInfor set userName='lmr2' where id=2");64 Console.WriteLine("按任意鍵進行事務提交");65 Console.ReadKey();66 try67 {68 tx.Commit();69 Console.WriteLine("事務提交成功");70 }71 catch (Exception ex)72 {73 tx.Rollback();74 Console.WriteLine("事務提交失敗");75 Console.WriteLine(ex.Message);76 }77 }78 }79 else if (num == "4")80 {81 using (LockDemoDBEntities1 db = new LockDemoDBEntities1())82 using (var tx = db.Database.BeginTransaction())83 {84 Console.WriteLine("開始查詢");85 //select的時候會對id=1的那行加上排它鎖，同時對整張表加上意向排它鎖，當別的線程查詢該表時，不用逐條去檢查資源86 //只需要看到該表存在【意向排它鎖】，就會等待，無論查詢id等于幾，都會等待87 var orderInfor = db.Database.SqlQuery<OrderInfor>("select * from OrderInfor (xlock) where id=1").FirstOrDefault();88 Console.WriteLine($"id為：{orderInfor.id},userName為：{orderInfor.userName},destination為：{orderInfor.destination}");89 90 Console.WriteLine("按任意鍵進行事務提交");91 Console.ReadKey();92 try93 {94 tx.Commit();95 Console.WriteLine("事務提交成功");96 }97 catch (Exception ex)98 {99 tx.Rollback(); 100 Console.WriteLine("事務提交失敗"); 101 Console.WriteLine(ex.Message); 102 } 103 } 104 } 105 106 107 }

結論：

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

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

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

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

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

　　證明：

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

　　證明：

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

1 {2 Console.WriteLine("測試更新鎖、排它鎖、共享鎖間的關系");3 Console.WriteLine("更新鎖業務輸入：1, 排它鎖業務輸入：2，共享鎖輸入：3");4 string num = Console.ReadLine();5 if (num == "1")6 {7 Console.WriteLine("更新鎖業務");8 using (LockDemoDBEntities1 db = new LockDemoDBEntities1())9 using (var tx = db.Database.BeginTransaction()) 10 { 11 Console.WriteLine("開始查詢"); 12 //顯式的添加更新鎖 13 var orderInfor = db.Database.SqlQuery<OrderInfor>("select * from OrderInfor(updlock) where id=2").FirstOrDefault(); 14 Console.WriteLine($"id為：{orderInfor.id},userName為：{orderInfor.userName},destination為：{orderInfor.destination}"); 15 Console.WriteLine("按任意鍵進行事務提交"); 16 Console.ReadKey(); 17 try 18 { 19 tx.Commit(); 20 Console.WriteLine("事務提交成功"); 21 } 22 catch (Exception ex) 23 { 24 tx.Rollback(); 25 Console.WriteLine("事務提交失敗"); 26 Console.WriteLine(ex.Message); 27 } 28 } 29 } 30 else if (num == "2") 31 { 32 Console.WriteLine("排它鎖業務"); 33 using (LockDemoDBEntities1 db = new LockDemoDBEntities1()) 34 using (var tx = db.Database.BeginTransaction()) 35 { 36 Console.WriteLine("開始更新"); 37 //update的時候會自動加排它鎖 38 var result = db.Database.ExecuteSqlCommand("update OrderInfor set userName='lmr2' where id=2"); 39 Console.WriteLine("按任意鍵進行事務提交"); 40 Console.ReadKey(); 41 try 42 { 43 tx.Commit(); 44 Console.WriteLine("事務提交成功"); 45 } 46 catch (Exception ex) 47 { 48 tx.Rollback(); 49 Console.WriteLine("事務提交失敗"); 50 Console.WriteLine(ex.Message); 51 } 52 } 53 } 54 else if (num == "3") 55 { 56 Console.WriteLine("共享鎖業務"); 57 using (LockDemoDBEntities1 db = new LockDemoDBEntities1()) 58 using (var tx = db.Database.BeginTransaction()) 59 { 60 Console.WriteLine("開始查詢"); 61 //select的時候會自動加共享鎖 62 var orderInfor = db.Database.SqlQuery<OrderInfor>("select * from OrderInfor where id=2").FirstOrDefault(); 63 Console.WriteLine($"id為：{orderInfor.id},userName為：{orderInfor.userName},destination為：{orderInfor.destination}"); 64 Console.WriteLine("按任意鍵進行事務提交"); 65 Console.ReadKey(); 66 try 67 { 68 tx.Commit(); 69 Console.WriteLine("事務提交成功"); 70 } 71 catch (Exception ex) 72 { 73 tx.Rollback(); 74 Console.WriteLine("事務提交失敗"); 75 Console.WriteLine(ex.Message); 76 } 77 } 78 } 79 }

結論：

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

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

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

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

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

1 {2 Console.WriteLine("測試表鎖和排它鎖的問題");3 Console.WriteLine("表鎖業務輸入：1, 排它鎖業務輸入：2");4 string num = Console.ReadLine();5 if (num == "1")6 {7 Console.WriteLine("表鎖業務");8 using (LockDemoDBEntities1 db = new LockDemoDBEntities1())9 using (var tx = db.Database.BeginTransaction()) 10 { 11 Console.WriteLine("開始查詢"); 12 13 var orderInfor = db.Database.SqlQuery<OrderInfor>("select * from OrderInfor(tablock) where id=2").FirstOrDefault(); 14 Console.WriteLine($"id為：{orderInfor.id},userName為：{orderInfor.userName},destination為：{orderInfor.destination}"); 15 Console.WriteLine("按任意鍵進行事務提交"); 16 Console.ReadKey(); 17 try 18 { 19 tx.Commit(); 20 Console.WriteLine("事務提交成功"); 21 } 22 catch (Exception ex) 23 { 24 tx.Rollback(); 25 Console.WriteLine("事務提交失敗"); 26 Console.WriteLine(ex.Message); 27 } 28 } 29 } 30 else if (num == "2") 31 { 32 Console.WriteLine("排它鎖業務"); 33 using (LockDemoDBEntities1 db = new LockDemoDBEntities1()) 34 using (var tx = db.Database.BeginTransaction()) 35 { 36 Console.WriteLine("開始更新"); 37 //update的時候會自動加排它鎖 38 var result = db.Database.ExecuteSqlCommand("update OrderInfor set userName='lmr2' where id=2"); 39 Console.WriteLine("按任意鍵進行事務提交"); 40 Console.ReadKey(); 41 try 42 { 43 tx.Commit(); 44 Console.WriteLine("事務提交成功"); 45 } 46 catch (Exception ex) 47 { 48 tx.Rollback(); 49 Console.WriteLine("事務提交失敗"); 50 Console.WriteLine(ex.Message); 51 } 52 } 53 } 54 }

?結論：

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

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

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

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

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

1 {2 Console.WriteLine("測試行鎖和排它鎖的問題");3 Console.WriteLine("行鎖業務輸入：1, 排它鎖業務輸入：2");4 string num = Console.ReadLine();5 if (num == "1")6 {7 Console.WriteLine("行鎖業務");8 using (LockDemoDBEntities1 db = new LockDemoDBEntities1())9 using (var tx = db.Database.BeginTransaction()) 10 { 11 Console.WriteLine("開始查詢"); 12 13 var orderInfor = db.Database.SqlQuery<OrderInfor>("select * from OrderInfor(rowlock) where id=2").FirstOrDefault(); 14 Console.WriteLine($"id為：{orderInfor.id},userName為：{orderInfor.userName},destination為：{orderInfor.destination}"); 15 Console.WriteLine("按任意鍵進行事務提交"); 16 Console.ReadKey(); 17 try 18 { 19 tx.Commit(); 20 Console.WriteLine("事務提交成功"); 21 } 22 catch (Exception ex) 23 { 24 tx.Rollback(); 25 Console.WriteLine("事務提交失敗"); 26 Console.WriteLine(ex.Message); 27 } 28 } 29 } 30 else if (num == "2") 31 { 32 Console.WriteLine("排它鎖業務"); 33 using (LockDemoDBEntities1 db = new LockDemoDBEntities1()) 34 using (var tx = db.Database.BeginTransaction()) 35 { 36 Console.WriteLine("開始更新"); 37 //update的時候會自動加排它鎖 38 var result = db.Database.ExecuteSqlCommand("update OrderInfor set userName='lmr2' where id=1"); 39 Console.WriteLine("按任意鍵進行事務提交"); 40 Console.ReadKey(); 41 try 42 { 43 tx.Commit(); 44 Console.WriteLine("事務提交成功"); 45 } 46 catch (Exception ex) 47 { 48 tx.Rollback(); 49 Console.WriteLine("事務提交失敗"); 50 Console.WriteLine(ex.Message); 51 } 52 } 53 } 54 }

結論：

　　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不住的。
拓展殺死鎖和進程

1 --檢測死鎖2 --如果發生死鎖了，我們怎么去檢測具體發生死鎖的是哪條SQL語句或存儲過程？3 --這時我們可以使用以下存儲過程來檢測，就可以查出引起死鎖的進程和SQL語句。SQL Server自帶的系統存儲過程sp_who和sp_lock也可以用來查找阻塞和死鎖, 但沒有這里介紹的方法好用。 4 5 use master6 go7 create procedure sp_who_lock8 as9 begin10 declare @spid int,@bl int,11 @intTransactionCountOnEntry int,12 @intRowcount int,13 @intCountProperties int,14 @intCounter int15 16 create table #tmp_lock_who (17 id int identity(1,1),18 spid smallint,19 bl smallint)20 21 IF @@ERROR<>0 RETURN @@ERROR22 23 insert into #tmp_lock_who(spid,bl) select 0 ,blocked24 from (select * from sysprocesses where blocked>0 ) a 25 where not exists(select * from (select * from sysprocesses where blocked>0 ) b 26 where a.blocked=spid)27 union select spid,blocked from sysprocesses where blocked>028 29 IF @@ERROR<>0 RETURN @@ERROR 30 31 -- 找到臨時表的記錄數32 select @intCountProperties = Count(*),@intCounter = 133 from #tmp_lock_who34 35 IF @@ERROR<>0 RETURN @@ERROR 36 37 if @intCountProperties=038 select '現在沒有阻塞和死鎖信息' as message39 40 -- 循環開始41 while @intCounter <= @intCountProperties42 begin43 -- 取第一條記錄44 select @spid = spid,@bl = bl45 from #tmp_lock_who where Id = @intCounter 46 begin47 if @spid =0 48 select '引起數據庫死鎖的是: '+ CAST(@bl AS VARCHAR(10)) + '進程號,其執行的SQL語法如下'49 else50 select '進程號SPID：'+ CAST(@spid AS VARCHAR(10))+ '被' + '進程號SPID：'+ CAST(@bl AS VARCHAR(10)) +'阻塞,其當前進程執行的SQL語法如下'51 DBCC INPUTBUFFER (@bl )52 end 53 54 -- 循環指針下移55 set @intCounter = @intCounter + 156 end57 58 drop table #tmp_lock_who59 60 return 061 end62 63 64 --殺死鎖和進程65 --如何去手動的殺死進程和鎖？最簡單的辦法，重新啟動服務。但是這里要介紹一個存儲過程，通過顯式的調用，可以殺死進程和鎖。66 67 use master68 go69 70 if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[p_killspid]') and OBJECTPROPERTY(id, N'IsProcedure') = 1)71 drop procedure [dbo].[p_killspid]72 GO73 74 create proc p_killspid75 @dbname varchar(200) --要關閉進程的數據庫名76 as 77 declare @sql nvarchar(500) 78 declare @spid nvarchar(20)79 80 declare #tb cursor for81 select spid=cast(spid as varchar(20)) from master..sysprocesses where dbid=db_id(@dbname)82 open #tb83 fetch next from #tb into @spid84 while @@fetch_status=085 begin 86 exec('kill '+@spid)87 fetch next from #tb into @spid88 end 89 close #tb90 deallocate #tb91 go92 93 --用法 94 exec p_killspid 'newdbpy' 95 96 --查看鎖信息97 --如何查看系統中所有鎖的詳細信息？在企業管理管理器中，我們可以看到一些進程和鎖的信息，這里介紹另外一種方法。98 --查看鎖信息99 create table #t(req_spid int,obj_name sysname) 100 101 declare @s nvarchar(4000) 102 ,@rid int,@dbname sysname,@id int,@objname sysname 103 104 declare tb cursor for 105 select distinct req_spid,dbname=db_name(rsc_dbid),rsc_objid 106 from master..syslockinfo where rsc_type in(4,5) 107 open tb 108 fetch next from tb into @rid,@dbname,@id 109 while @@fetch_status=0 110 begin 111 set @s='select @objname=name from ['+@dbname+']..sysobjects where id=@id' 112 exec sp_executesql @s,N'@objname sysname out,@id int',@objname out,@id 113 insert into #t values(@rid,@objname) 114 fetch next from tb into @rid,@dbname,@id 115 end 116 close tb 117 deallocate tb 118 119 select 進程id=a.req_spid 120 ,數據庫=db_name(rsc_dbid) 121 ,類型=case rsc_type when 1 then 'NULL 資源（未使用）' 122 when 2 then '數據庫' 123 when 3 then '文件' 124 when 4 then '索引' 125 when 5 then '表' 126 when 6 then '頁' 127 when 7 then '鍵' 128 when 8 then '擴展盤區' 129 when 9 then 'RID（行 ID)' 130 when 10 then '應用程序' 131 end 132 ,對象id=rsc_objid 133 ,對象名=b.obj_name 134 ,rsc_indid 135 from master..syslockinfo a left join #t b on a.req_spid=b.req_spid 136 137 go 138 drop table #t

?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'

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

?

?

?

?

總結

以上是生活随笔為你收集整理的第二十二节: 以SQLServer为例介绍数据库自有的锁机制(共享锁、更新锁、排它锁等）和事务隔离级别 :的全部內容，希望文章能夠幫你解決所遇到的問題。

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