[轉帖]SQL祕笈 ： NOLOCK、ROWLOCK、UPDLOCK的使用！

NOLOCK的使用  
NOLOCK可以忽略鎖，直接從數據庫讀取數據。這意味着可以避開鎖，從而提高性能和擴展性。但同時也意味着代碼出錯的可能性存在。你可能會讀取到運行事務正在處理的無須驗證的未遞交數據。 這種風險可以量化。
如果是金融方面的代碼或者一些非常規的總計(你想絕對保證安全性)，你應該小心行事並且不使用這種技術。但是我認爲使用該技術會比你90%應用系統性能要好，當用戶  (或者是交互代碼)  發現一個未遞交的修改時，使用該技術會保證不會像未使用該技術那樣引起大麻煩。實際上，你可能發現你的大多數數據很少或者甚至不進行修改的，這樣我們就不會因爲這些數據被鎖住而浪費大量的時間。   
例如，如果你想統計在2009年6月到8月之間某網站的註冊用戶，就沒有理由去鎖住任何記錄：  2009年9月1號一到來，這個用戶數就是確定的。   
ROWLOCK的使用
ROWLOCK告訴  SQL    Server只使用行級鎖。ROWLOCK語法可以使用在SELECT,  UPDATE和DELETE語句中，不過  我習慣僅僅在UPDATE和DELETE語句中使用。如果在UPDATE語句中有指定的主鍵，那麼就總是會引發行級鎖的。但是當SQL    Server對幾個這種UPDATE進行批處理時，某些數據正好在同一個頁面(page)，這種情況在當前情況下    是很有可能發生的，這就象在一個folder中，創建一個新文件需要較長的時間，而同時你又要去更新該folder中的某些文件。當頁面鎖引發後，事情就開始變得糟糕了。而如果在UPDATE或者DELETE 時，沒有指定主鍵，數據庫當然認爲很多數據會收到影響，那樣  就會直接引發頁面鎖，事情同樣變得糟糕。
通過指定使用行級鎖，這種情況可以得到避免。但是需要小心的是，如果你錯誤地使用在過多行上，數據庫並不會聰明到自動將行級鎖升級到頁面鎖，服務器也會因爲行級鎖的開銷而消耗大量的內存和CPU，直至無法響應。尤其主要留意的是  企業管理器中"管理/當前活動"(Management /Current    Activity)這一項。該項會花較長的時間來載入鎖的信息。這些信息是十分有用的，當你使用行級鎖後，你如果在"鎖/處理" (Locks/Processes)下看到幾百個鎖，一點都不奇怪，而恰恰應該慶幸鎖超時和死鎖的問題減少了。     
注意事項
我認爲SQL    Server傾向於使用NOLOCK關鍵字，而ROWLOCK關鍵字由用戶根據情況自行決定。你可以僅僅在    SELECT語句中使用NOLOCK，這些SELECT語句場合包括Join查詢，以及在INSERT語句中的SELECT使用，例如：     
SELECT    COUNT(U.UserID)    FROM    Users    U  WITH    (NOLOCK) 
inner  join    UsersInUserGroups    UG    WITH    (NOLOCK)    ON      U.UserID    =    UG.UserID     
NOLOCK    和    ROWLOCK的使用效果
很難去量化在使用NOLOCK和ROWLOCK後，Streamload.com網站給我們了一個信息。  使用NOLOCK和ROWLOCK 前，Streamload.com的速度很慢，而且經常無法使用，以及很不穩定。使用後，就變得快速、容易訪問以及穩定了。兩者簡直就是天壤之別。這些改變當然無法在  關於鎖的文檔中很難找到。那些文檔會建議你重寫你的應用，當表數據被使用，鎖產生了(沒錯，就是這樣)，然後你應該使用小事務並且以批處理的形式執行(不錯，實際經驗就是如此)，使用低級別的隔離措施    (也沒錯，NOLOCK就是一個極端的例子)，還建議你有限的連接，從而讓處理器進行合作(好複雜的描述，而且總覺得怪怪的不像個好點子)。我不知道是否用數據庫諮詢師會提到本文中的技術(或類似的技術)，  但是我只想說的是，Streamload.com的運行狀況的確因爲該技術得到了改善。如果你遇到了鎖爭用的問題，也可以試試NOLOCK和ROWLOCK。   
申明
是否使用NOLOCK和ROWLOCK，需要自行判斷，並謹慎運用。我用該技術的情況是：在併發性很高的數據庫中select自己想要的數據。我需要判斷如果用NOLOCK  而引起一些返回的不準確，或者ROWLOCK是否會造成太多的鎖，這些情況出現時，對於訪問者或者使用者來說，是否是可以接受的。在大多數情況下，我認爲是沒有問題的，但是也許你的代碼不適用，你需要小心對待。你需要創建一些獨立的過程，是否加鎖，如何加鎖，以作爲對比。當 UPDATE  或者    DELETE查詢影響到很多數據行時，你在使用PAGELOCK,  TABLOCK時也會遇到別的問題.

UPDLOCK　　讀取表時使用更新鎖，而不使用共享鎖，並將鎖一直保留到語句或事務的結束。UPDLOCK 的優點是允許您讀取數據（不阻塞其它事務）並在以後更新數據，同時確保自從上次讀取數據後數據沒有被更改。　　這是SqlServer2000中對更新鎖的說明.　　 當我們用UPDLOCK來讀取記錄時可以對取到的記錄加上更新鎖，從而加上鎖的記錄在其它的線程中是不能更改的只能等本線程的事務結束後才能更改，我如下示例：BEGIN TRANSACTION --開始一個事務
SELECT Qty
FROM myTable WITH (UPDLOCK)
WHERE Id in (1,2,3)
UPDATE myTable SET Qty = Qty - A.Qty
FROM myTable   AS A
INNER JOIN   @_Table AS B ON A.ID = B.ID
COMMIT TRANSACTION --提交事務　　這樣在更新時其它的線程或事務在這些語句執行完成前是不能更改ID是１，２，３的記錄的．其它的都可以修改和讀，１，２，３的只能讀，要是修改的話只能等這些語句完成後才能操作.從而保證的數據的修改正確. 

文章知識點與官方知識檔案匹配，可進一步學習相關知識

MySQL入門技能樹SQL高級技巧CTE和遞歸查詢83493 人正在系統學習中