1.瘋狂的“獨佔”行鎖

譯文：
昨天我發現了SQL SERVER一些確實很怪異的行為。我有一個案例我竟然可以讀取被其他會話置了“獨佔”鎖的記錄。看到“獨佔”這個詞，你想到的一定是：一個事務擁有獨佔行鎖那麼其它事務就不能讀取該行了。但是這有特例：你可以讀取被其它被別人獨佔鎖定的行。
它花了我和同事很多時間，最終才發現到底是怎麼回事。

為了重現這種行為，你需要一個測試表，表裡有一些隨機資料。

CREATE TABLE [MyTable]
 ([Col1] bigint PRIMARY KEY CLUSTERED, [Col2] bigint)
INSERT INTO [MyTable] ([Col1], [Col2]) VALUES (1,10)
INSERT INTO [MyTable] ([Col1], [Col2]) VALUES (2,20)
INSERT INTO [MyTable] ([Col1], [Col2]) VALUES (3,30)
INSERT INTO [MyTable] ([Col1], [Col2]) VALUES (4,40)
INSERT INTO [MyTable] ([Col1], [Col2]) VALUES (5,50)

只要資料庫沒有開啟快照隔離，你可以將測試表放在任何資料庫中，而且恢復模式也對它沒有影響。
下面我們來執行一些查詢，看看會發生什麼。為了能正確地測試，你需要對同一測試表執行兩個不同的會話。為了能一直持有已分配的鎖，你需要啟動一個事務、執行一些命令，但是千萬不要結束事務。
首先在查詢分析器的第一個視窗中（我們稱之為會話1）查詢表中的某一行，並且使用提示XLOCK和ROWLOCK獲得一個獨佔的行鎖。
會話 1:
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
BEGIN TRAN
SELECT Col1 FROM [MyTable] WITH (XLOCK, ROWLOCK) WHERE [Col1] = 3

為了核實鎖的情況，我們執行sp_locks來看看到底為會話1授予了哪些鎖：

spid   dbid   ObjId       IndId  Type Resource                   Mode     Status
------ ------ ----------- ------ ---- -------------------------------- --------    ------
56     21     69575286    1      PAG  1:41                              IX       GRANT
56     21     69575286    1      KEY  (030075275214)           X        GRANT
56     21     69575286    0      TAB                                       IX       GRANT

你可以看到有一個“X”（獨佔）鎖在表的第一個鍵上。（其他的鎖是“IX”意向鎖）。現在開始第2個連線，看看如果要讀這條記錄會發生什麼？
會話 2:
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
BEGIN TRAN
SELECT Col1 FROM [MyTable] WHERE [Col1] = 3

我很希望這條語句被“掛住”，一直等到這條記錄有效為止。但我吃驚地發現這條記錄可以被非常順利的讀出。同時,sp_locks顯示系統沒有為這條指令分配任何其他鎖，即使一個共享鎖也沒有。

如果你回滾會話2（為了撇清所有其它可能的情況）然後用表提示HOLDLOCK重新執行就會得到你想要的結果了：會話2中現在需要等待會話1中的事務完成了。

為了理解所發生的事，你需要回憶一下讀提交隔離級別中的一條規則：可以讀任何已經被提交的行。這裡我們讀的行時“乾淨的”（它沒有被系統標為“髒的”），此時系統優化器會決定可以直接通過索引取資料而不需要檢查鎖的情況，所以表中甚至都不需要主鍵，只要有索引包含請求的資料，行鎖就不需要了。

所以如果被鎖住的記錄並沒有變化，被請求的列包含在索引中，那麼從READ COMMITTTED隔離級別上就獨佔鎖可能就沒什麼用了。

一種解決方法是在會話2的SELECT上加“HOLDLOCK”表提示。或者你也可以真的在會話1中更新記錄，這樣該記錄就擁有獨佔鎖了（而且還被標為“髒的”）。還有一種解決方法是用PAGLOCK鎖住整個也而不僅僅是一行，此時獨佔鎖會鎖住該頁中的所有行。

網上有人發了一篇

結論：
這花了我很多時間來找出到底發生了什麼事。所以記住：在SELECT語句中使用XLOCK和ROWLOCK提示並不意味著只有你一個人能讀這些資料行。

2.UPDATE 時, 如何避免資料定位處理被阻塞

問題描述:

資料庫PUBS中的authors表，想鎖定CITY為aaa的記錄，為什麼執行下面的命令後，CITY為bbb的記錄也被鎖定了，無法進行UPDATE.

BEGIN TRANSACTION    

    SELECT * FROM authors

    WITH (HOLDLOCK)

    WHERE city='aaa'

如何才能鎖定CITY為AAA的記錄，而且CITY為BBB的記錄依然能SELECT和UPDATE？

問題分析：

應該不是被鎖住，應該只是檢索資料的時候，需要從aaa的記錄掃描到bbb的記錄，而aaa被鎖住了，所以掃描無法往下進行，這樣看起來似乎就是bbb也被鎖住了。

當然，也有可能確實是被鎖住了，SQL Server的鎖定預設是行級的，如果你的資源不足，則可能導致鎖自動升級為頁級甚至表級鎖，這樣會導致更多的記錄被鎖定。

使用下面的語句, 如果能讀出資料, 則多半是第1種情況.

SELECT *

FROM authors WITH (READPAST)

WHERE city='bbb'

如果讀不出資料, 則一般是第2種情況.

問題解決方法：

讓SELECT 和UPDATE 走不同的索引，這樣在UPDATE 的時候，不用掃描已經鎖定的資料就可以定義到記錄，UPDATE 也就不會被阻塞了

指定索引用類似下面的語句:

SELECT *

FROM authors WITH (HOLDLOCK, INDEX=索引名)

WHERE city='aaa'

UPDATE A SET

    xx = xx

FROM authors A WITH (INDEX=索引名)

WHERE city='bbb'

當然，要保證僅掃描索引就可以定義到記錄，否則可能還是會被阻塞。

補充

對於熟悉SQL Server鎖的讀者，可以通過 sp_lock，或者查詢系統表 master.dbo.syslocks、master.dbo.syslockinfo來確定行為。