伴隨著時間的增長，公司的數(shù)據(jù)庫會越來越多，查詢速度也會越來越慢。打開數(shù)據(jù)庫看到幾十萬條的數(shù)據(jù)，查詢起來難免不廢時間。

要提升SQL的查詢效能，一般來說大家會以建立索引(index)為第一考慮。其實除了index的建立之外，當我們在下SQL Command時，在語法中加一段WITH (NOLOCK)可以改善在線大量查詢的環(huán)境中數(shù)據(jù)集被LOCK的現(xiàn)象藉此改善查詢的效能。

不過有一點千萬要注意的就是，WITH (NOLOCK)的SQL SELECT有可能會造成Dirty Read，就是讀到無效的數(shù)據(jù)。

下面對于SQLSERVER的鎖爭用及nolock,rowlock的原理及使用作一個簡單描述：

鎖爭用的描述

那些不僅僅使用行級鎖的數(shù)據(jù)庫使用一種稱為混和鎖(lock escalation)的技術來獲取較高的性能。除非很明確知道是針對整個數(shù)據(jù)表，否則這些數(shù)據(jù)庫的做法是開始使用行級鎖， 然后隨著修改的數(shù)據(jù)增多，開始使用大范圍的鎖機制。

不幸的是，這種混和鎖的方法會產(chǎn)生和放大新的問題：死鎖。如果兩個用戶以相反的順序修改位于不同表的記錄，而這兩條記錄雖然邏輯上不相關， 但是物理上是相鄰的，操作就會先引發(fā)行鎖，然后升級為頁面鎖。這樣， 兩個用戶都需要對方鎖定的東西，就造成了死鎖。

例如：

用戶A修改表A的一些記錄，引發(fā)的頁面鎖不光鎖定正在修改的記錄，還會有很多其它記錄也會被鎖定。

用戶B修改表B的一些記錄，引發(fā)的頁面鎖鎖定用戶A和其它正在修改的數(shù)據(jù)。

用戶A想修改用戶B在表B中鎖定(并不一定正在修改的)數(shù)據(jù)。

用戶B想修改或者僅僅想訪問用戶A在表A中鎖定(并不一定正在修改)的數(shù)據(jù)。

為了解決該問題，數(shù)據(jù)庫會經(jīng)常去檢測是否有死鎖存在，如果有，就把其中的一個事務撤銷，好讓另一個事務能順利完成。一般來說，都是撤銷 那個修改數(shù)據(jù)量少的事務，這樣回滾的開銷就比較少。使用行級鎖的數(shù)據(jù)庫 很少會有這個問題，因為兩個用戶同時修改同一條記錄的可能性極小，而且由于極其偶然的修改數(shù)據(jù)的順序而造成的鎖也少。

而且，數(shù)據(jù)庫使用鎖超時來避免讓用戶等待時間過長。查詢超時的引入也是為了同樣目的。我們可以重新遞交那些超時的查詢，但是這只會造成數(shù)據(jù)庫的堵塞。如果經(jīng)常發(fā)生超時，說明用戶使用SQL Server的方式有問題。正常情況是很少會發(fā)生超時的。

在服務器負載較高的運行環(huán)境下，使用混合鎖的SQL Server鎖機制，表現(xiàn)不會很好。 原因是鎖爭用(Lock Contention)。鎖爭用造成死鎖和鎖等待問題。在一個多用戶系統(tǒng)中，很多用戶會同時在修改數(shù)據(jù)庫，還有更多的用戶在同時訪問數(shù)據(jù)庫，隨時會產(chǎn)生鎖，用戶也爭先恐后地獲取鎖以確保自己的操作的正確性，死鎖頻繁發(fā)生，這種情形下，用戶的心情可想而知。

確實，如果只有少量用戶，SQL Server不會遇到多少麻煩。內(nèi)部測試和發(fā)布的時候，由于用戶較少，也很難發(fā)現(xiàn)那些并發(fā)問題。但是當激發(fā)幾百個并發(fā)，進行持續(xù)不斷地INSERT,UPDATE，以及一些 DELETE操作時，如何觀察是否有麻煩出現(xiàn)，那時候你就會手忙腳亂地去解鎖。

鎖爭用的解決方法

SQL Server開始是用行級鎖的，但是經(jīng)常會擴大為頁面鎖和表鎖，最終造成死鎖。

即使用戶沒有修改數(shù)據(jù)，SQL Server在SELECT的時候也會遇到鎖。幸運的是，我們可以通過SQL Server 的兩個關鍵字來手工處理：NOLOCK和ROWLOCK。

它們的使用方法如下：

SELECT COUNT(UserID)
　FROM Users WITH (NOLOCK)
　WHERE Username LIKE 'football'

和

UPDATE Users WITH (ROWLOCK)
SET Username = 'admin' WHERE Username = 'football'

NOLOCK的使用

NOLOCK可以忽略鎖，直接從數(shù)據(jù)庫讀取數(shù)據(jù)。這意味著可以避開鎖，從而提高性能和擴展性。但同時也意味著代碼出錯的可能性存在。你可能會讀取到運行事務正在處理的無須驗證的未遞交數(shù)據(jù)。 這種風險可以量化。

ROWLOCK的使用

ROWLOCK告訴SQL Server只使用行級鎖。ROWLOCK語法可以使用在SELECT,UPDATE和DELETE語句中，不過 我習慣僅僅在UPDATE和DELETE語句中使用。如果在UPDATE語句中有指定的主鍵，那么就總是會引發(fā)行級鎖的。但是當SQL Server對幾個這種UPDATE進行批處理時，某些數(shù)據(jù)正好在同一個頁面(page)，這種情況在當前情況下 是很有可能發(fā)生的，這就象在一個目錄中，創(chuàng)建文件需要較長的時間，而同時你又在更新這些文件。當頁面鎖引發(fā)后，事情就開始變得糟糕了。而如果在UPDATE或者DELETE時，沒有指定主鍵，數(shù)據(jù)庫當然認為很多數(shù)據(jù)會收到影響，那樣 就會直接引發(fā)頁面鎖，事情同樣變得糟糕。

下面寫一個例子，來說明一下NOLOCK的作用，這里使用一個有一萬多條的數(shù)據(jù)庫來測試，先不用NOLOCK來看一下：

declare @start DATETIME;
declare @end DATETIME;
SET @start = getdate();
select * from Captions_t;
SET @end = getdate();
select datediff(ms,@start,@end);

這里為了是效果更加明顯，使用了Select * ，來看一下執(zhí)行結果，如下圖：

這里顯示的使用時間是34720ms,下面使用NOLOCK來看一下：

declare @start DATETIME;
declare @end DATETIME;
SET @start = getdate();
select * from Captions_t18 with (NOLOCK);
SET @end = getdate();
select datediff(ms,@start,@end);

運行結果如下圖：

這次使用的時間是2563ms，差距體現(xiàn)出來了吧。個人感覺時間不應該差這么多，總之性能是提高了不少。

nolock和with(nolock)的幾個小區(qū)別：

1.SQL Server 2005中的同義詞，只支持with(nolock);

2.with(nolock)的寫法非常容易再指定索引。

3.跨服務器查詢語句時，不能用with (nolock) 只能用nolock，同一個服務器查詢時則with (nolock)和nolock都可以用。比如：select * from [IP].a.dbo.table1 with (nolock) 這樣會提示錯誤，select * from a.dbo.table1 with (nolock) 這樣就可以成功地查詢。

以上內(nèi)容就是本文介紹sql server 性能優(yōu)化之nolock的全部內(nèi)容，希望對大家有所幫助。

版權聲明：本站文章來源標注為YINGSOO的內(nèi)容版權均為本站所有，歡迎引用、轉載，請保持原文完整并注明來源及原文鏈接。禁止復制或仿造本網(wǎng)站，禁止在非www.sddonglingsh.com所屬的服務器上建立鏡像，否則將依法追究法律責任。本站部分內(nèi)容來源于網(wǎng)友推薦、互聯(lián)網(wǎng)收集整理而來，僅供學習參考，不代表本站立場，如有內(nèi)容涉嫌侵權，請聯(lián)系alex-e#qq.com處理。