公司資料庫随着時間的增長,資料越來越多,查詢速度也越來越慢。進資料庫看了一下,幾十萬調的資料,查詢起來确實很費時間。
要提升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。
它們的使用方法如下:
和
NOLOCK的使用
NOLOCK可以忽略鎖,直接從資料庫讀取資料。這意味着可以避開鎖,進而提高性能和擴充性。但同時也意味着代碼出錯的可能性存在。你可能會讀取到運作事務正在處理的無須驗證的未遞交資料。 這種風險可以量化。
ROWLOCK的使用
ROWLOCK告訴SQL Server隻使用行級鎖。ROWLOCK文法可以使用在SELECT,UPDATE和DELETE語句中,不過 我習慣僅僅在UPDATE和DELETE語句中使用。如果在UPDATE語句中有指定的主鍵,那麼就總是會引發行級鎖的。但是當SQL Server對幾個這種UPDATE進行批處理時,某些資料正好在同一個頁面(page),這種情況在目前情況下 是很有可能發生的,這就象在一個目錄中,建立檔案需要較長的時間,而同時你又在更新這些檔案。當頁面鎖引發後,事情就開始變得糟糕了。而如果在UPDATE或者DELETE時,沒有指定主鍵,資料庫當然認為很多資料會收到影響,那樣 就會直接引發頁面鎖,事情同樣變得糟糕。
下面寫一個例子,來說明一下NOLOCK的作用,這裡使用一個有一萬多條的資料庫來測試,先不用NOLOCK來看一下:
這裡為了是效果更加明顯,使用了Select * ,來看一下執行結果,如下圖:

這裡顯示的使用時間是34720ms,下面使用NOLOCK來看一下:
運作結果如下圖:
這次使用的時間是2563ms,差距展現出來了吧。個人感覺時間不應該差這麼多,總之性能是提高了不少。大家多多測試看看吧~~
參考文章:http://blog.sina.com.cn/s/blog_7034dbe00100ll9n.html