在SQL Server裏咱們爲何須要意向鎖（Intent Locks）？

在1年前，我寫了篇在SQL Server裏爲何咱們須要更新鎖。今天我想繼續這個討論，談下SQL Server裏的意向鎖，還有爲何須要它們。

SQL Server裏的鎖層級

當我討論SQL Server裏的鎖升級時，我從SQL Server使用的鎖層級開始題，在你讀或修改你的數據的時候。

當你讀取一條記錄時，SQL Server默認請求一個共享鎖（S），當你修改一條記錄時，SQL Server請求一個排它鎖（X）。這2個鎖彼此不兼容，當你同時向讀寫一條記錄時，會發生阻塞。

另外對於行級別的鎖，在鎖層級裏，SQL Server也會在更高一層請求所謂的意向鎖（Intent Locks）：在頁和表層級。SQL Server基於請求的行級別鎖，請求下列的意向鎖：

• 意向共享鎖（Intent Shared Lock (IS)），當你在行層級有一個共享鎖（S）
• 意向更新鎖（Intent Update Lock (IU)），當你在行層級有一個更新鎖（U）
• 意向排它鎖（Intent Exclusive Lock (IX)），當你在行層級有一個排它鎖（X）

所以當讀或寫你記錄時，你總會得到如上圖所示的鎖層級。當SQL Server爲何使用這些意向鎖呢？

SQL Server裏的意向鎖

從技術上來講，SQL Server並不真的須要意向鎖。這和性能優化有關。咱們來具體看下。有了意向鎖，SQL Server代表在鎖層級裏更高層級上，你須要請求其餘鎖。意向共享鎖（Intent Shared Lock）告訴SQL Server某個地方有共享鎖（S）。對於意向更新鎖（Intent Update Lock）或意向排它鎖（Intent Exclusive Lock）也是同樣，但此次SQL Server知道在某個地方有更新鎖（Update Lock）或排它鎖（Exclusive Lock）。這只是個標識，沒別的。

但這個標識怎麼幫助SQL Server性能優化？假設你再表層級請求一個排它鎖（X）。在這個狀況下，SQL Server須要知道在某個記錄上是否有不兼容的鎖（像共享鎖（S）或更新鎖（U））。沒有意向鎖，SQL Server須要檢查每條記錄來看是否有一個授予的不兼容鎖。

但在表層級有意向共享鎖（IS）的話，SQL Server立刻知道在某個地方有授予的共享鎖（S），所以在表層級不能請求排它鎖（X）。這個就是SQL Server裏存在乎向鎖的緣由：在鎖層級裏，若是某個地方有不兼容的鎖存在，可讓SQL Server快速查到。很簡單，是否是？

小結

技術上，SQL Server不須要意向鎖，由於它只表示在鎖層級裏，某個地方有一些其餘特定類型的鎖。當基於若是你想在頁或表上請求特定的鎖，SQL Server能夠更高效的檢查是否有不兼容的鎖存在，仍是須要有意向鎖。

感謝關注！

原文連接：

https://www.sqlpassion.at/archive/2016/05/16/why-do-we-need-intent-locks-in-sql-server/