關於SQL Server的鎖定機制

Question

我想問一下關於SQL服務器，如果我不使用鎖提示與SQL語句的鎖定機制

1. 幾個問題時，SQL Server默認使用PAGELOCK提示。我對嗎？？？如果是，那爲什麼？可能是由於管理太多鎖的原因，這是我作爲缺點採取的唯一事情，但請讓我知道是否有其他人。並告訴我，如果我們可以改變這種默認行爲，如果它合理的話。我寫了一個服務器端應用程序，一個同步服務器（不使用同步框架），我寫了C＃代碼文件中的數據庫查詢，並使用ODBC連接執行它們。現在問題是什麼是最好的方式來改變從頁面到行的默認鎖定記住缺點（例如，在查詢中添加鎖定提示，這是我的計劃）。

2. 如果在沒有事務範圍的情況下執行SQL查詢（SELECT/DML），並且語句包含鎖定提示，那麼將獲取什麼樣的鎖定（例如共享，更新，獨佔）？而在事務範圍內，如果使用ROWLOCK提示，則事務的隔離級別會影響鎖定類型。

3. 最後，如果一些能夠給我品嚐，所以我可以測試所有上述情況我自己的經驗（如點網代碼或SQL腳本）

感謝 Mubashar

Answer 1

1. 不會。它鎖定它認爲合適的位置並根據需要升級鎖

2. 讓數據庫引擎管理它

3. 看點二

4. 看點二

，如果你想具體和特定行爲，例如queues或非阻塞（髒）讀我只用鎖提示。

更一般地說，爲什麼您認爲數據庫引擎默認情況下不能執行您想要的操作？

Answer 2

默認鎖定是行鎖而不是頁鎖，雖然鎖定機制的工作方式意味着您將鎖定層次結構中的所有對象，例如讀取單個行將在該表上放置共享鎖，在該頁上放置共享鎖，然後在該行上放置共享鎖。

這使得在桌子上請求排它鎖的動作就知道它可能不採取它，因爲有一個共享鎖存在（否則它會檢查每一頁/行的鎖。）

但是，如果您針對單個查詢發出過多的鎖，則會執行鎖升級，這會降低鎖的粒度 - 因此它會管理較少的鎖。 這可以使用跟蹤標誌關閉，但我不會考慮它。

直到你知道你實際上有一個鎖定/鎖升級問題，你可能會過早地優化一個不存在的問題。