今天我想講解乙個特別的問題，在我每次講解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不在主鍵上建立聚集索引的話，可能會導致大部分的表都是堆結構，而堆結構是亂序存放的，檢索很不方便，空間也不好管理，所以微軟就來了個強硬的，如果不在建表的同事...