每次講解SQL Server里的鎖和阻塞（Locking Blocking）都會碰到的問題：在SQL Server里，為什么我們需要更新鎖？在我們講解具體需要的原因前，首先我想給你介紹下當(dāng)更新鎖（Update（U）Lock）獲得時(shí)，根據(jù)它的兼容性鎖本身是如何應(yīng)對的。

一般來說，當(dāng)執(zhí)行UPDATE語句時(shí)，SQL Server會用到更新鎖（Update Lock）。如果你查看對應(yīng)的執(zhí)行計(jì)劃，你會看到它包含3個(gè)部分：

讀取數(shù)據(jù)
計(jì)算新值
寫入數(shù)據(jù)

在查詢計(jì)劃的第1部分，SQL Server初始讀取要修改的數(shù)據(jù)，在各個(gè)記錄上會獲得更新鎖（Update Locks）。在查詢計(jì)劃的最后第3部分，當(dāng)數(shù)據(jù)被修改時(shí)，這些更新鎖（Update Locks）轉(zhuǎn)化為排它鎖（Exclusive（X））。用這個(gè)方法產(chǎn)生的問題都是一樣的：在第1個(gè)階段，SQL Server為什么要獲得更新鎖（Update Locks），而不是共享鎖（Shared（S） Locks）。平常當(dāng)你通過SELECT語句讀取數(shù)據(jù)，共享鎖（Shared（S） Locks）已經(jīng)夠用了。現(xiàn)在的更新查詢計(jì)劃為什么有這個(gè)區(qū)別？我們來詳細(xì)分析下。

回避死鎖（Deadlock Avoidance）
首先在更新查詢計(jì)劃里，更新鎖用來避免死鎖情形。假設(shè)在計(jì)劃的第1階段，有多個(gè)更新查詢計(jì)劃獲得共享鎖（Shared（S）Locks），然后在查詢計(jì)劃的第3階段，當(dāng)數(shù)據(jù)最后被修改時(shí)，這些共享鎖（Shared Locks）轉(zhuǎn)化為排它鎖（Exclusive Loks），會發(fā)生什么：

第1個(gè)查詢不能轉(zhuǎn)化共享鎖為排它鎖，因?yàn)榈?個(gè)查詢已經(jīng)獲得了共享鎖。
第2個(gè)查詢不能轉(zhuǎn)化共享鎖為排它鎖，因?yàn)榈?個(gè)查詢已經(jīng)獲得了共享鎖。

這是其中一個(gè)主要原因，為什么關(guān)系數(shù)據(jù)庫引擎引入更新鎖來實(shí)現(xiàn)避免特定的死鎖情形。一個(gè)更新鎖只與一個(gè)共享鎖兼容，但不與另一個(gè)更新或排它鎖兼容。因此死鎖情形可以被避免，應(yīng)為2個(gè)更新查詢計(jì)劃不可能同時(shí)并發(fā)運(yùn)行。在查詢的第1階段，第2個(gè)查詢會一直等到獲得更新鎖。System R的一個(gè)未公開研究也展示如何避免這類顯著的死鎖。System R不實(shí)用任何更新鎖來實(shí)現(xiàn)避免死鎖。

提升的并發(fā)

在第1階段不獲得更新鎖，在這個(gè)階段直接獲得排它鎖也是可見選項(xiàng)。這會克服死鎖問題，因?yàn)榕潘i與另一個(gè)排它鎖不兼容。但這個(gè)方法的問題是并發(fā)受限制，因?yàn)橥瑫r(shí)沒有其他的SELECT查詢可以讀取當(dāng)前有排它鎖的數(shù)據(jù)。因此需要更新鎖，因?yàn)檫@個(gè)特定鎖與傳統(tǒng)的共享鎖兼容。這樣的話其他的SELECT查詢可以讀取數(shù)據(jù)，只要這個(gè)更新鎖還沒轉(zhuǎn)化為排它鎖。作為副作用，這會提高我們并發(fā)運(yùn)行查詢的并發(fā)性。

在以前關(guān)系學(xué)術(shù)上，更新鎖是所謂的非對稱鎖（Asymmetric Lock）。在更新鎖的上下文里，這個(gè)更新鎖與共享鎖兼容，但反之就不是：共享鎖與更新鎖不兼容。但SQL Server并不把共享鎖作為非對稱鎖實(shí)現(xiàn)。更新鎖是個(gè)對稱（symmetric）的，就是說更新鎖和共享鎖是彼此雙向兼容的。這會提供系統(tǒng)的整體并發(fā)，因?yàn)樵?個(gè)鎖類型鍵不會引入阻塞情形。

小結(jié)
在今天的文章里我給你介紹了共享鎖，還有為什么需要共享鎖。如你所見在關(guān)系數(shù)據(jù)庫，是強(qiáng)烈需要更新鎖的，因?yàn)椴蝗坏木蜁硭梨i并降低并發(fā)。我希望現(xiàn)在你已經(jīng)很好的理解了更新鎖，還有在SQL Server里它們是如何使用的。

以上就是本文的全部內(nèi)容了，希望大家可以喜歡。