SQLServer效能優化之 nolock，大幅提升資料庫查詢效能

雲霏霏發表於2014-07-16
SQLServer優化資料庫

　　公司資料庫隨著時間的增長，資料越來越多，查詢速度也越來越慢。進資料庫看了一下，幾十萬調的資料，查詢起來確實很費時間。

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

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

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

鎖爭用的描述

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

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

例如：

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

　　使用者B修改表B的一些記錄，引發的頁面鎖鎖定使用者A和其它正在修改的資料。

　　使用者A想修改使用者B在表B中鎖定(並不一定正在修改的)資料。

　　使用者B想修改或者僅僅想訪問使用者A在表A中鎖定(並不一定正在修改)的資料。

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

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

　　在伺服器負載較高的執行環境下，使用混合鎖的SQL Server鎖機制，表現不會很好。 原因是鎖爭用(Lock Contention)。鎖爭用造成死鎖和鎖等待問題。在一個多使用者系統中，很多使用者會同時在修改資料庫，還有更多的使用者在同時訪問資料庫，隨時會產生鎖，使用者也爭先恐後地獲取鎖以確保自己的操作的正確性，死鎖頻繁發生，這種情形下，使用者的心情可想而知。

　　確實，如果只有少量使用者，SQL Server不會遇到多少麻煩。內部測試和釋出的時候，由於使用者較少，也很難發現那些併發問題。但是當激發幾百個併發，進行持續不斷地INSERT,UPDATE，以及一些 DELETE操作時，如何觀察是否有麻煩出現，那時候你就會手忙腳亂地去解鎖。

 

鎖爭用的解決方法

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

　　即使使用者沒有修改資料，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可以忽略鎖，直接從資料庫讀取資料。這意味著可以避開鎖，從而提高效能和擴充套件性。但同時也意味著程式碼出錯的可能性存在。你可能會讀取到執行事務正在處理的無須驗證的未遞交資料。 這種風險可以量化。

ROWLOCK的使用

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

下面寫一個例子，來說明一下NOLOCK的作用，這裡使用一個有一萬多條的資料庫來測試，先不用NOLOCK來看一下：

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

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

這裡顯示的使用時間是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，差距體現出來了吧。個人感覺時間不應該差這麼多，總之效能是提高了不少。大家多多測試看看吧~~

 

參考文章：http://blog.sina.com.cn/s/blog_7034dbe00100ll9n.html

相關文章