在SQL Server裡為什麼我們需要更新鎖

2021-09-22 07:06:44 字數 1530 閱讀 2626

今天我想講解乙個特別的問題,在我每次講解sql server裡的鎖和阻塞(locking & blocking)都會碰到的問題:在sql server裡,為什麼我們需要更新鎖?在我們講解具體需要的原因前,首先我想給你介紹下當更新鎖(update(u)lock)獲得時,根據它的相容性鎖本身是如何應對的。

一般來說,當執行update語句時,sql server會用到更新鎖(update lock)。如果你檢視對應的執行計畫,你會看到它包含3個部分

在查詢計畫的第1部分,sql server初始讀取要修改的資料,在各個記錄上會獲得更新鎖(update locks)。在查詢計畫的最後第3部分,當資料被修改時,這些更新鎖(update locks)轉化為排它鎖(exclusive(x))。用這個方法產生的問題都是一樣的:在第1個階段,sql server為什麼要獲得更新鎖(update locks),而不是共享鎖(shared(s) locks)。平常當你通過select語句讀取資料,共享鎖(shared(s) locks)已經夠用了。現在的更新查詢計畫為什麼有這個區別?我們來詳細分析下。

首先在更新查詢計畫裡,更新鎖用來避免死鎖情形。假設在計畫的第1階段,有多個更新查詢計畫獲得共享鎖(shared(s)locks),然後在查詢計畫的第3階段,當資料最後被修改時,這些共享鎖(shared locks)轉化為排它鎖(exclusive loks),會發生什麼:

這是其中乙個主要原因,為什麼關聯式資料庫引擎引入更新鎖來實現避免特定的死鎖情形。乙個更新鎖只與乙個共享鎖相容,但不與另乙個更新或排它鎖相容。因此死鎖情形可以被避免,應為2個更新查詢計畫不可能同時併發執行。在查詢的第1階段,第2個查詢會一直等到獲得更新鎖。system r的乙個未公開研究也展示如何避免這類顯著的死鎖。system r不使用任何更新鎖來實現避免死鎖。

提公升的併發

在第1階段不獲得更新鎖,在這個階段直接獲得排它鎖也是可見選項。這會克服死鎖問題,因為排它鎖與另乙個排它鎖不相容。但這個方法的問題是併發受限制,因為同時沒有其他的select查詢可以讀取當前有排它鎖的資料。因此需要更新鎖,因為這個特定鎖與傳統的共享鎖相容。這樣的話其他的select查詢可以讀取資料,只要這個更新鎖還沒轉化為排它鎖。作為***,這會提高我們併發執行查詢的併發性。

在以前關係學術上,更新鎖是所謂的非對稱鎖(asymmetric lock)。在更新鎖的上下文裡,這個更新鎖與共享鎖相容,但反之就不是:共享鎖與更新鎖不相容。但sql server並不把共享鎖作為非對稱鎖實現。更新鎖是個對稱(symmetric)的,就是說更新鎖和共享鎖是彼此雙向相容的。這會提供系統的整體併發,因為在2個鎖型別鍵不會引入阻塞情形。

在今天的文章裡我給你介紹了共享鎖,還有為什麼需要共享鎖。如你所見在關聯式資料庫,是強烈需要更新鎖的,因為不然的就會帶來死鎖並降低併發。我希望現在你已經很好的理解了更新鎖,還有在sql server裡它們是如何使用的。

在SQL Server裡為什麼我們需要更新鎖

今天我想講解乙個特別的問題,在我每次講解sql server裡的鎖和阻塞 locking blocking 都會碰到的問題 在sql server裡,為什麼我們需要更新鎖?在我們講解具體需要的原因前,首先我想給你介紹下當更新鎖 update u lock 獲得時,根據它的相容性鎖本身是如何應對的。一...

我為什麼在joyo購書 2

昨晚幾乎在相同的時間,我在joyo和dangdang都訂了書。今天觀察了二者的發貨速度,有點感想想寫下來。值此新年之際,也祝閱讀此文的朋友新年快樂!首先我不是偏執狂,更不是閒來沒事非要跑二個 訂書,更加談不上槍手了,說的只是我做為乙個普通消費者的實際經歷和感受,如果說感受是主觀的,那麼經歷總算是客觀...

SqlServer為什麼自動在主鍵上建立聚集索引

微軟推薦為每乙個表建立乙個聚集索引,但是由於sqlserver簡單易用,而且很多人並不了解聚集索引,非聚集索引這些東西,所以如果sqlserver不在主鍵上建立聚集索引的話,可能會導致大部分的表都是堆結構,而堆結構是亂序存放的,檢索很不方便,空間也不好管理,所以微軟就來了個強硬的,如果不在建表的同事...