SQL NOLOCK大雜燴

標籤：問題   main   blank   儲存   復原   pos   今天   總結   amp   

今天碰到NOLOCK 的問題，就查閱了一些資料，做了相關瞭解；總結了比較經典，樸實的兩篇在此。

電梯直達：

SQL Server 中WITH (NOLOCK)淺析

文章本想大篇幅摘抄，因為擔心連結失效或作者隱藏（刪掉）。不過，最終還是只放個連結至此，以作參考。

為什麼NOLOCK反而返回更少的資料

註：

allocation scan：也就是通過叢集索引葉子節點的鏈表來做橫向掃描的

 range scan：通過檢索IAM對資料頁的物理先後（pageid）來進行掃描

NOLOCK　　--百度

以前遇到過，但僅限於聽同事說加上NOLOCK好一些，今天仔細研究測試了下，終於理解了，那麼加與不加到底區別在哪呢？ 我先說下其區別，之後再做測試。 大家都知道，每建立一個查詢，都相當於建立一個會話，在不同的查詢分析器裡面進行的操作，可以影響到其他會話的查詢，極端的情況可能會一直處於阻塞中，哪怕只是一個很簡單的查詢都“特別慢”。 BEGIN TRAN 是開始一個事務的意思，開始之後可執行一些SQL語句，接著需要執行COMMIT進行提交或者ROLLBACK進行復原，否則就會出現上面的情況。但如果使用NOLOCK進行查詢的時候，就不會因為別的回話沒有提交或復原，而受阻塞。所以概括起來，可以用以下語句來總結： NOLOCK能使當前會話的查詢，不受其它會話的事務所阻塞。但是這樣做，就讀取了其它事務的“修改後未提交的”資料。 現在我們進行測試，一定要注意，必須在多個會話下才可以，也就是說，需要建三個查詢分析器視窗。 表用最簡單的表，自己動手建一個。 查詢分析器一：執行 SELECT * FROM dbo.test_main 得到 id value1 one2 two3 three4 four 接著執行如下： BEGIN TRAN
INSERT INTO test_main VALUES(5, ‘five‘) 一行受影響 查詢分析器二：執行 SELECT * FROM dbo.test_main 則卡死，受上一會話所阻塞。查不出結果。 補充：那麼卡死怎麼辦呢？我們已經說過，要執行提交或者復原操作才可以，那麼在會話一中執行COMMIT即可。 之後此查詢立刻顯示結果。 查詢分析器三：執行 SELECT * FROM test_main(NOLOCK) 則顯示如下 id value1 one2 two3 three4 four 5 five 但最後一行並沒有真正儲存在資料庫中，因為會話一還沒有進行提交，我們用NOLOCK就查詢出來了。 也許你會想，那什麼情況下用NOLOCK呢？經過我們的分析，用NOLOCK是為了避免出現卡死狀態，那我們就可以分析其環境了。 一個經常操作的表，並且每次操作都很重要，這樣一般要用到事務進行處理，因為可以避免出錯的幾率，我們查詢時，要用NOLOCK，否則遇上卡死的幾率很大。別人執行一個事務，還沒處理完呢，你就查詢了，那就卡死了。有了NOLOCK就可以解決這個問題了。

SQL NOLOCK大雜燴