sqlserver 鎖 - 轉

鎖是一種防止在某對象執行動做的一個進程與已在該對象上執行的其餘進行相沖突的機制。也就是說，若是有其餘人在操做某個對象，那麼你舊不能在該對象上進行操做。你可否執行操做取決於其餘用戶正在進行的操做。

經過鎖能夠防止的問題

　　鎖能夠解決如下4種主要問題：

• 髒讀
• 非重複性讀取
• 幻讀
• 丟失更新

　　一、髒讀

　　若是一個事務讀取的記錄是另外一個未完成事務的一部分，那麼這時就發生了髒讀。若是第一個事務正常完成，那麼就有什麼問題。可是，若是前一個事務回滾了呢，那將從數據庫從未發生的事務中獲取了信息。

　　二、非重複性讀取

　　很容易將非重複性讀取和髒讀混淆。若是一個事務中兩次讀取記錄，而另外一個事務在這期間改變了數據，就會發生非重複性讀取。
例如，一個銀行帳戶的餘額是不容許小於0的。若是一個事務讀取了某帳戶的餘額爲125元，此時另外一事務也讀取了125元，若是兩個事務都扣費100元，那麼這時數據庫的餘額就變成了-75元。

　　有兩種方式能夠防止這個問題：

• 建立CHECK約束並監控547錯誤
• 將隔離級別設置爲REPEATABLEREAD或SERIALIZABLE

　　CHECK約束看上去至關直觀。要知道的是，這是一種被動的而非主動的方法。然而，在不少狀況下可能須要使用非重複性讀取，因此這在不少狀況下是首選。

　　三、幻讀

　　幻讀發生的機率很是小，只有在很是偶然的狀況下才會發生。

　　好比，你想將一張工資表裏全部低於100的人的工資，提升到100元。你可能會執行如下SQL語句：

　　UPDATE tb_Money SET Salary = 100
　　WHERE Salary < 100

　　這樣的語句，一般狀況下，沒有問題。可是若是，你在UPDATE的過程當中，有人剛好有INSERT了一條工資低於100的數據，由於這是一個全新的數據航，因此沒有被鎖定，並且它會被漏過Update。

　　要解決這個問題，惟一的方法是設定事務隔離級別爲SERIALIZABLE,在這種狀況下，任何對錶的更新都不能放入WHERE子句中，不然他們將被鎖在外面。

　　四、丟失更新

　　丟失更新發生在一個更新成功寫入數據庫後，而又意外地被另外一個事務重寫時。這是怎麼發生的呢？若是有兩個事務讀取整個記錄，而後其中一個向記錄寫入了更新信息，而另外一個事務也向該記錄寫入更新信息，這是就會出現丟失更新。

　　有個例子寫得很好，這裏照敲下來吧。假如你是公司的一位信用分析員，你接到客戶X打開的電話，說他已達到它的信用額度上限，想申請增長額度，因此你查看了這位客戶的信息，你發現他的信用額度是5000，而且看他每次都能按時付款。

　　當你在查看的時候，信用部門的另外一位員工也讀取了客戶X的記錄，並輸入信息改變了客戶的地址。它讀取的記錄也顯示信用額度爲5000。

　　這時你決定把客戶X的信用額度提升到10000，而且按下了Enter鍵，數據庫如今顯示客戶X的信用額度爲10000。

　　Sally如今也更新了客戶X的地址，可是她仍然使用和您同樣的編輯屏幕，也就是說，她更新了整個記錄。還記得她屏幕上顯示的信用額度嗎？是5000.數據庫如今又一次顯示客戶X的信用額度爲5000。你的更新丟失了。

　　解決這個問題的方法取決於你讀取某數據和要更新數據的這段時間內，代碼以何種方式識別出另外一鏈接已經更新了該記錄。這個識別的方式取決於你所使用的訪問方法。

能夠鎖定的資源

對於SQL Server來講，有6種可鎖定的資源，並且它們造成了一個層次結構。鎖的層次越高，它的粒度就越粗。按粒度由粗到細排列，這些資源包括：

• 數據庫：鎖定整個數據庫。這一般發生在整個數據庫模式改變的時候。
• 表：鎖定整個表。這包含了與該表相關聯的全部數據相關的對象，包括實際的數據行(每一行)以及與該表相關聯的全部索引中的鍵。
• 區段：鎖定整個區段。由於一個區段由8頁組成，因此區段鎖定是指鎖定控制了區段、控制了該區段內8個數據或索引頁以及這8頁中的全部數據航。
• 頁：鎖定該頁中的全部數據或索引鍵。
• 鍵：在索引中的特定鍵或一系間上有鎖。相同索引頁中的其餘鍵不受影響。
• 行或行標識符：雖然從技術上將，鎖是放在行標識符上的，可是本質上，它鎖定了整個數據行。

鎖升級和鎖對性能的影響

　　升級是指可以認識到維持一個較細的粒度(例如，行鎖而不是頁鎖)，只在被鎖定的項數較少時有意義。而隨着愈來愈多的項目被鎖定，維護這些鎖的系統開銷實際上會影響性能。這會致使所持續更長的時間。

　　當維持鎖的數量達到必定限度時，則鎖升級爲下一個更高的層次，而且將不須要再如此緊密地管理低層次的鎖(釋放資源，並且有助於提高速度)。

　　注意，升級是基於鎖的數量，而不是用戶的數量。這裏的重點是，能夠經過執行大量的更新來單獨地鎖定表-行鎖能夠升級爲頁鎖，頁鎖能夠升級爲表鎖。這意味着可能將全部其餘用戶鎖在該表以外。若是查詢使用了多個表，則它極可能將每一個人鎖在這些表以外。

鎖定模式

　　除了須要考慮鎖定的資源層次之外，還要考慮查詢將要得到的鎖定模式，就像須要對不一樣的資源進行鎖定同樣，也有不一樣的鎖定模式。一些模式是互相排斥的。一些模式什麼都不作，只修改其餘的模式。模式是否能夠一塊兒使用取決於他們是不是兼容的。

　　一、共享鎖

　　這是最基本的一種鎖。共享鎖用於只須要讀取數據的時候，也就是說，共享鎖鎖定時，不會進行改變內容的操做，其餘用戶容許讀取。

　　共享鎖能和其餘共享鎖兼容。雖然共享鎖不介意其餘鎖的存在，可是有些鎖並不能和共享鎖共存。

　　共享鎖告訴其餘鎖，某用戶已經在那邊了，它們並不提供不少的功能，可是不能忽略它們。然而，共享鎖能作的是防止用戶執行髒讀。

　　二、排它鎖

　　排它鎖顧名思義，排它鎖不與其餘任何鎖兼容。若是有任何其餘其餘鎖存在，則不能使用排他鎖，並且當排他鎖仍然起做用時，他們不容許在資源之上建立任何形式的新鎖。這能夠防止兩我的同時更新、刪除或執行任何操做。

　　三、更新鎖

　　更新鎖是共享鎖和排他鎖的混合。更新鎖是一種特殊的佔位符。爲了能執行UPDATE，須要驗證WHERE子句來指出想要更新的具體的數據行。這意味着只須要一個共享鎖，直到真正地進行物理更新。在物理更新期間，須要一個排他鎖。

• 第一個階段指出了知足WHERE子句條件的內容，這是更新查詢的一部分，該查詢有一個更新鎖。
• 第二個階段是若是決定執行更新，那麼鎖將升級爲排他鎖。不然，將把鎖轉換爲共享鎖。

　　這樣作的好處是它防止了死鎖。死鎖自己不是一種鎖定類型，而是一種已經造成矛盾的情況，兩個鎖在互相等待，多個鎖造成一個環在等待前面的事務清除資源。

　　若是沒有更新鎖，死鎖會一直出現。兩個更新查詢會在共享模式下運行。Query A完成了它的查詢工做並準備進行物理更新。它想升級爲排他鎖，可是不能夠這麼作，由於Query B正在完成查詢。除非Query B須要進行物理更新，不然它會完成查詢。爲了作到這點，Query B必須升級爲排他鎖，可是不能這麼作，由於Query A正在等待。這樣就形成了僵局。

　　而更新鎖阻止創建其餘的更新鎖。第二個事務只要嘗試取得一個更新鎖，它們就會進入等待狀態，直到超時爲止-將不會授予這個鎖。若是第一個鎖在鎖超時以前清除的話，則鎖定會授予給新的請求者，而且這個處理會繼續下去。若是不清楚，則會發生錯誤。

　　更新鎖只與共享鎖以及意向共享鎖相兼容。

　　四、意向鎖

　　意向鎖是什麼意思呢？就是說，加入你鎖定了某一行，那麼同時也加了表的意向鎖(不容許其餘人經過表鎖來妨礙你)。

　　意向鎖是真正的佔位符，它用來處理對象層次問題的。假設一下以下狀況：已對某一行創建了鎖，可是有人想在頁上或區段上創建所，或者是修改表。你確定不想讓另外一個事務經過達到更高的層次來妨礙你。
　　若是沒有意向鎖，那麼較高層次的對象將不會知道在較低層次上有鎖。意向鎖可改進性能，由於SQL Server只須要在表層次上檢查意向鎖(而不須要檢查表上的每一個行鎖或者頁鎖)，以此來決定事務是否能夠安全地鎖定整個表。

　　意向鎖分爲如下3種不一樣的類型：

• 意向共享鎖：該意向鎖指已經或者將要在層次結構的一些較低點處創建共享鎖。
• 意向排他鎖：它與意向共享鎖同樣，可是將會在低層項上設置排他鎖。
• 共享意向排他鎖：它指已經或將會在對象層次結構下面創建共享鎖，但目的是爲了修改數據，因此它會在某個時刻成爲意向排它鎖。

　　五、模式鎖

　　模式鎖分爲如下兩種。

• 　　模式修改鎖：對對象進行模式改變。在Sch-M鎖期間，不能對對象進行查詢或其餘CREATE、ALTER或DROP語句的操做。
• 　　模式穩定鎖鎖定：它和共享鎖很類似;這個鎖的惟一目的是方式模式修改鎖，由於在該對象上已有其餘查詢(或CREATE、ALTER、DROP語句)的鎖。它與其餘全部的鎖定相兼容。

　　六、批量更新鎖

　　批量更新鎖(BU)只是一種略有不一樣的表鎖定變體形式。批量更新鎖容許並行加載數據。也就是說，對於其餘任何普通操做(T-SQL)都會將表鎖定，但能夠同時執行多個BULK INSERT或bcp操做。

鎖的兼容性

　　鎖的資源鎖定模式的兼容性表格，現有鎖以列顯示，要兼容的鎖以行顯示。

鎖的類型	意向共享鎖(IS)	共享鎖(S)	更新鎖(U)	意向排他鎖(IX)	共享意向排它鎖(SIX)	排他鎖(X)
意向共享鎖(IS)	是	是	是	是	是	否
共享鎖(S)	是	是	是	否	否	否
更新鎖(U)	是	是	否	否	否	否
意向排他鎖(IX)	是	否	否	是	否	否
共享意向排它鎖(SIX)	是	否	否	否	否	否
排他鎖(X)	否	否	否	否	否	否

　　另外:

• 　　Sch-S與出Sch-M之外的全部鎖定模式相兼容。
• 　　Sch-M和全部的鎖定模式不兼容。
• 　　BU只與模式穩定性鎖以及其餘的批量更新鎖相兼容。

　　有時想要在查詢中或在整個事務中對鎖定有更多的控制。能夠經過使用優化器提示(optimizer hints)來實現這一點。

　　優化器提示明確告訴SQL Server將一個鎖升級爲特有的層次。這些提示信息包含在將要影響的表的名稱以後。

　　優化器提示是一個高級主題，有經驗的SQL Server開發人員會常用它，而且他們至關重視它。

　　使用Management Studio肯定鎖

　　查看鎖的最好方式是使用Management Studio。經過使用Activity Monitor，Management Studio會以兩種方式顯示鎖-經過processId或object。

　　爲了使用Management Studio顯示鎖，只要導航到<Server>的Activity Monitor節點，其中的<Server>是監控其活動的服務器的頂級節點。

　　展開感興趣的節點(Overview部分默認展開)，能夠經過滾動條查看大量度量值-包括當前系統中有效的鎖。

　　

　　顯示界面以下：
　　

設置隔離級別

　　事務和鎖之間的聯繫是很緊密的。默認狀況下，一旦建立了任何與數據修改相關的鎖，該鎖定就會在整個事務期間存在。若是有一個大型事務，就意味着將在很長一段時間內阻止其餘進程訪問鎖定的對象。這明顯是有問題的。

事務有5種隔離級別：

• READ COMMITTED
• READ UNCOMMITTED
• REPEATABLE READ
• SERIALIZABLE
• SNAPSHOT

　　在這些隔離級別之間進行切換的語法也至關直觀：

　　SET TRANSACTION ISOLATION LEVEL < READ COMMITTED | READ UNCOMMITTED | REPEATABLE READ | SERIALIZABLE | SNAPSHOT >

　　對隔離級別的修改只會影響到當前的鏈接-因此沒必要擔憂會影響到其餘的用戶。其餘用戶也影響不了你。

　　一、READ COMMITTED

　　默認狀況就是這個，經過READ COMMITTED，任何建立的共享鎖將在建立它們的語句完成後自動釋放。也就是說，若是啓動了一個事務，運行了一些語句，而後運行SELECT語句，再運行一些其餘的語句，那麼當SELECT語句完成的時候，與SELECT語句相關聯的鎖就會釋放 - SQL Server並不會等到事務結束。

　　動做查詢(UPDATE、DELETE、INSERT)有點不一樣。若是事務執行了修改數據的查詢，則這些鎖將會在事務期間保持有效。

　　經過設置READ COMMITTED這一默認隔離級別，能夠肯定有足夠的數據完整性來防止髒讀。然而，仍會發生非重複性讀取和幻讀。

　　二、READ UNCOMMITTED

　　READ UNCOMMITTED是全部隔離級別中最危險的，可是它在速度方面有最好的性能。
　　設置隔離級別爲READ UNCOMMITTED將告訴SQL Server不要設置任何鎖，也不要事先任何鎖。
　　鎖既是你的保護者，同時也是你的敵人。鎖能夠防止數據完整性問題，可是鎖也常常妨礙或阻止你訪問須要的數據。因爲此鎖存在髒讀的危險，所以此鎖只能應用於並不是十分精確的環境中。

　　三、REPEATABLE READ

　　REPEATABLE READ會稍微地將隔離級別升級，並提供一個額外的併發保護層，這不只能防止髒讀，並且能防止非重複性讀取。
防止非重複性讀取是很大的優點，可是直到事務結束還保持共享鎖會阻止用戶訪問對象，所以會影響效率。推薦使用其餘的數據完整性選項，例如CHECK約束，而不是採用這個選擇。
　　與REPEATABLE READ隔離級別等價的優化器提示是REPEATABLEREAD(除了一個空格，二者並沒有不一樣)。

　　四、SERIALIZABLE

　　SERIALIZABLE是堡壘級的隔離級別。除了丟失更新之外，它防止全部形式的併發問題。甚至能防止幻讀。

　　若是設置隔離級別爲SERIALIZABLE，就意味着對事物使用的表進行的任何UPDATE、DELETE、INSERT操做絕對不知足該事務中任何語句的WHERE子句的條件。從本質上說，若是用戶想執行一些事務感興趣的事情，那麼必須等到該事務完成的時候。

　　SERIALIZABLE隔離級別也能夠經過查詢中使用SERIALIZABLE或HOLDLOCK優化器提示模擬。再次申明，相似於READ UNCOMMITTED和NOLOCK，前者不須要每次都設置，然後者須要把隔離級別設置回來。

　　五、SNAPSHOT

　　SNAPSHOT是最新的一種隔離級別，很是想READ COMMITTED和READ UNCOMMITTED的組合。要注意的是，SNAPSHOT默認是不可用的-只有爲數據庫打開了ALLOW_SNAPSHOT_ISOLATION特殊選項時，SNAPSHOT纔可用。
　　和READ UNCOMMITED同樣，SNAPSHOT並不建立任何鎖，也不實現人和所。二者的主要區別是它們識別數據庫中不一樣時段發生的更改。數據庫中的更改，無論什麼時候或是否提交，都會被運行READ UNCOMMITTED隔離級別的查詢看到。而使用SNAPSHOT，只能看到在SNAPSHOT事務開始以前提交的更改。從SNAPSHOT事務一開始執行，全部查看到的數據就和在時間開始時提交的同樣。

處理死鎖

　　死鎖的錯誤號是1205。

　　若是一個鎖因爲另外一個鎖佔有資源而不能完成應該作的清除資源工做，就會致使死鎖；反之亦然。當發生死鎖時，須要其中的一方贏得這場鬥爭，因此SQL Server選擇一個死鎖犧牲者，對死鎖犧牲者的事務進行回滾，而且經過1205錯誤來通知發生了死鎖。另一個事務將繼續正常地運行。

　　一、判斷死鎖的方式

　　每隔5秒鐘，SQL Server就會檢查全部當前的事務，瞭解他們在等待什麼還未被授予的鎖。而後再一次從新檢查全部打開的鎖請求的狀態，若是先前請求中有一個尚未被授予，則它會遞歸地檢查全部打開的事務，尋找鎖定請求的循環鏈。若是SQL Server找到這樣的村換連，則將會選擇一個或更多的死鎖犧牲者。

　　二、選擇死鎖犧牲者的方式

　　默認狀況下，基於相關事務的"代價"，選擇死鎖犧牲者。SQL Server將會選擇回滾代價最低的事務。在必定程度上，可使用SQL Server中的DEADLOCK_PRIORITY SET選項來重寫它。

　　三、避免死鎖

避免死鎖的經常使用規則

按相同的順序使用對象
• 使事務儘量簡短而且在一個批處理中。
• 儘量使用最低的事務隔離級別。
• 在同一事務中不容許無限度的中斷。
• 在控制環境中，使用綁定鏈接。

　　一、按相同的順序使用對象

　　例若有兩個表：Suppliers和Products。假設有兩個進程將使用這兩個表。進程1接受庫存輸入，用手頭新的產品總量更新Products表，接下來用已經購買的產品總量來更新Suppliers表。進程2記錄銷售數據，它在Supperlier表中更新銷售產品的總量，而後在Product中減小庫存數量。

　　若是同時運行這兩個進程，那麼就有可能碰到麻煩。進程1試圖獲取Product表上的一個排他鎖。進程2將在Suppliers表上獲取一個排他鎖。而後進程1將試圖獲取Suppliers表上的一個鎖，可是進程1必須等到進程2清除了現有的鎖。同時進程2也在等待進程1清除現有鎖。

　　上面的例子是，兩個進程用相反的順序，鎖住兩個表，這樣就很容易發生死鎖。

　　若是咱們將進程2改爲首先在Products減小庫存數量，接着在Suppliers表中更新銷售產品的總數量。兩個進程以相同的順序訪問兩張表，這樣就可以減小死鎖的發生。

　　二、使事務儘量簡短

　　保持事務的簡短將不會讓你付出任何的代價。在事務中放入想要的內容，把不須要的內容拿出來，就這麼簡單。它的原理並不複雜-事務打開的時間越長，它觸及的內容就越多，那麼其餘一些進程想要獲得正在使用的一個或者多個對象的可能性就越大。若是要保持事務簡短，那麼就將最小化可能引發死鎖的對象的數量，還將減小鎖定對象的時間。原理就如此簡單。

　　三、儘量使用最低的事務隔離級別

　　使用較低的隔離級別和較高的隔離級別相比，共享鎖持續的時間更短，所以會減小鎖的競爭。

　　四、不要採用容許無限中斷的事務

當開始執行某種開放式進程時間，不要建立將一直佔有資源的鎖。一般，指的是用戶交互，但它也多是容許無限等待的任何進程。