第八節：數據庫層次的鎖機制詳解和事務隔離級別
一. 基本概念sql
1.共享鎖：(holdlock)數據庫
(1). select的時候會自動加上共享鎖，該條語句執行完，共享鎖當即釋放，與事務是否提交沒有關係。安全
(2). 顯式經過添加(holdlock)來顯式添加共享鎖（好比給select語句顯式添加共享鎖），當在事務裏的時候，須要事務結束，該共享鎖才能釋放。ide
(3). 同一資源，共享鎖和排它鎖不能共存，意味着update以前必須等資源上的共享鎖釋放後才能進行。性能
(4). 共享鎖和共享鎖能夠共存在一個資源上，意味着同一個資源容許多個線程同時進行select。測試
2. 排它鎖：(xlock)fetch
(1). update(或 insert 或 delete)的時候加自動加上排它鎖，該條語句執行完，排它鎖當即釋放，若是有事務的話，須要事務提交，該排它鎖才能釋放。搜索引擎
(2). 顯式的經過添加(xlock)來顯式的添加排它鎖（好比給select語句顯式添加排它鎖），若是有事務的話，須要事務提交，該排它鎖才能釋放。spa
(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 try 19 { 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 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 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 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 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 try 93 { 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 tran 3 begin try 4 set deadlock_priority -9 5 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 tran 9 end try 10 begin catch 11 rollback tran 12 end catch
1 -- 線程2測試(下面語句單獨開一個窗口進行測試) 2 begin tran 3 begin try 4 set deadlock_priority -8 5 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 tran 9 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 master 6 go 7 create procedure sp_who_lock 8 as 9 begin 10 declare @spid int,@bl int, 11 @intTransactionCountOnEntry int, 12 @intRowcount int, 13 @intCountProperties int, 14 @intCounter int 15 16 create table #tmp_lock_who ( 17 id int identity(1,1), 18 spid smallint, 19 bl smallint) 20 21 IF @@ERROR<>0 RETURN @@ERROR 22 23 insert into #tmp_lock_who(spid,bl) select 0 ,blocked 24 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>0 28 29 IF @@ERROR<>0 RETURN @@ERROR 30 31 -- 找到臨時表的記錄數 32 select @intCountProperties = Count(*),@intCounter = 1 33 from #tmp_lock_who 34 35 IF @@ERROR<>0 RETURN @@ERROR 36 37 if @intCountProperties=0 38 select '如今沒有阻塞和死鎖信息' as message 39 40 -- 循環開始 41 while @intCounter <= @intCountProperties 42 begin 43 -- 取第一條記錄 44 select @spid = spid,@bl = bl 45 from #tmp_lock_who where Id = @intCounter 46 begin 47 if @spid =0 48 select '引發數據庫死鎖的是: '+ CAST(@bl AS VARCHAR(10)) + '進程號,其執行的SQL語法以下' 49 else 50 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 + 1 56 end 57 58 drop table #tmp_lock_who 59 60 return 0 61 end 62 63 64 --殺死鎖和進程 65 --如何去手動的殺死進程和鎖？最簡單的辦法，從新啓動服務。可是這裏要介紹一個存儲過程，經過顯式的調用，能夠殺死進程和鎖。 66 67 use master 68 go 69 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 GO 73 74 create proc p_killspid 75 @dbname varchar(200) --要關閉進程的數據庫名 76 as 77 declare @sql nvarchar(500) 78 declare @spid nvarchar(20) 79 80 declare #tb cursor for 81 select spid=cast(spid as varchar(20)) from master..sysprocesses where dbid=db_id(@dbname) 82 open #tb 83 fetch next from #tb into @spid 84 while @@fetch_status=0 85 begin 86 exec('kill '+@spid) 87 fetch next from #tb into @spid 88 end 89 close #tb 90 deallocate #tb 91 go 92 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'
其它三種暫不測試了，與此一樣道理進行測試。
!
- 做 者 : Yaopengfei(姚鵬飛)
- 博客地址 : http://www.cnblogs.com/yaopengfei/
- 聲 明1 : 本人才疏學淺，用郭德綱的話說「我是一個小學生」，若有錯誤，歡迎討論，請勿謾罵^_^。
- 聲 明2 : 原創博客請在轉載時保留原文連接或在文章開頭加上本人博客地址，不然保留追究法律責任的權利。
- 1. 數據庫事務隔離級別和鎖實現機制
- 2. 事務的隔離級別和數據庫的事務機制
- 3. 數據庫-事務和隔離級別
- 4. 數據庫事務和隔離級別
- 5. 數據庫併發機制和事務的隔離級別詳解
- 6. 數據庫事務中的隔離級別和鎖
- 7. 數據庫事務隔離級別和鎖的實現方式
- 8. Spring事務傳播機制和數據庫隔離級別
- 9. 數據庫事務的隔離級別
- 10. 數據庫事務隔離級ORACLE數據庫事務隔離級別介紹
- 更多相關文章...
- • 事務的四大特性和隔離級別 - Hibernate教程
- • ARP協議的工作機制詳解 - TCP/IP教程
- • 漫談MySQL的鎖機制
- • Flink 數據傳輸及反壓詳解
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 數據庫事務隔離級別和鎖實現機制
- 2. 事務的隔離級別和數據庫的事務機制
- 3. 數據庫-事務和隔離級別
- 4. 數據庫事務和隔離級別
- 5. 數據庫併發機制和事務的隔離級別詳解
- 6. 數據庫事務中的隔離級別和鎖
- 7. 數據庫事務隔離級別和鎖的實現方式
- 8. Spring事務傳播機制和數據庫隔離級別
- 9. 數據庫事務的隔離級別
- 10. 數據庫事務隔離級ORACLE數據庫事務隔離級別介紹