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)
innerjoin
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時也會遇到別的問題.
NOLOCK可以忽略鎖，直接從資料庫讀取資料。這意味著可以避開鎖，從而提高效能和擴充套件性。但同時也意味著程式碼出錯的可能性存在。你可能會讀取到執行事務正在處理的無須驗證的未遞交資料。
如果是金融方面的程式碼或者一些非常規的總計(你想絕對保證安全性)，你應該小心行事並且不使用這種技術。但是我認為使用該技術會比你90%應用系統效能要好，當使用者
例如，如果你想統計在2009年6月到8月之間某網站的註冊使用者，就沒有理由去鎖住任何記錄：
ROWLOCK的使用
ROWLOCK告訴
透過指定使用行級鎖，這種情況可以得到避免。但是需要小心的是，如果你錯誤地使用在過多行上，資料庫並不會聰明到自動將行級鎖升級到頁面鎖，伺服器也會因為行級鎖的開銷而消耗大量的記憶體和CPU，直至無法響應。尤其主要留意的是
注意事項
我認為SQL
SELECT
inner
NOLOCK
很難去量化在使用NOLOCK和ROWLOCK後，Streamload.com網站給我們了一個資訊。
申明
是否使用NOLOCK和ROWLOCK，需要自行判斷，並謹慎運用。我用該技術的情況是：在併發性很高的資料庫中select自己想要的資料。我需要判斷如果用NOLOCK
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是１，２，３的記錄的．其它的都可以修改和讀，１，２，３的只能讀，要是修改的話只能等這些語句完成後才能操作.從而保證的資料的修改正確.
SELECT Qty
FROM myTable WITH (UPDLOCK)
WHERE Id in (1,2,3)
UPDATE myTable SET Qty = Qty - A.Qty
FROM myTable
INNER JOIN
COMMIT TRANSACTION --提交事務 這樣在更新時其它的執行緒或事務在這些語句執行完成前是不能更改ID是１，２，３的記錄的．其它的都可以修改和讀，１，２，３的只能讀，要是修改的話只能等這些語句完成後才能操作.從而保證的資料的修改正確.
文章知識點與官方知識檔案匹配，可進一步學習相關知識
MySQL入門技能樹SQL高階技巧CTE和遞迴查詢83493 人正在系統學習中