SQL Server - 確實[SELECT]鎖定[UPDATE]？

Question

我有一個複雜的選擇查詢和一個巨大的表。

我跑這個select聲明，同時一個Update聲明到來，並試圖更新表。

恕我直言 - 更新需要獨家鎖 - 這樣的更新語句將不得不等待直到選擇命令完成。

1. 對不起，對嗎？

2. 我該怎麼才能做到：執行復雜select，和也讓update命令運行（目前我不在乎髒數據）

Answer 1

是 - 學位。

一個SELECT取決於事務的隔離級別持有的共享鎖多久：

• READ UNCOMMITTED - 沒有共享鎖被收購的話 - UPDATE不堵塞
• READ COMMITTED - 共享僅在讀取數據期間獲取鎖 - UPDATE可能會在很短的時間內被阻止
• REPEATABLE READ和SERIALIZABLE - 共享鎖被獲取並保留在unti升的事務的結束 - UPDATE被阻塞，直到SELECT事務結束

技術上，UPDATE語句首先得到一個UPDATE鎖 - 其爲具有共享鎖（如所使用的SELECT）兼容 - 爲對持續時間當它正在讀取要更新的行的當前值時。

一旦完成，Update鎖升級爲獨佔鎖，以便將新數據寫入表中。

Answer 2

當您同時運行這兩個語句（SELECT和UPDATE）時，實際行爲將基本上是隨機的。這是因爲這兩種操作都不是即時的。爲了簡化，請將您的表視爲列表，並且SELECT正在遍歷此列表，一次查看一行。 UPDATE也試圖更新一個或多個行。當UPDATE嘗試更新後面的行時，SELECT將不會發生任何事情（無阻塞），因爲SELECT已經超越了UPDATE點。如果UPDATE試圖更新SELECT正在查找的行現在那麼UPDATE將不得不等待SELECT繼續前進，這將發生得非常非常快，並且UPDATE將取消阻止併成功，而 SELECT正在向前邁進。但是，如果更新正在更新前面的SELECT，那麼更新將成功，並且，後面的，SELECT最終將到達此行並停止，阻止。現在SELECT必須等待，直到執行UPDATE的事務提交。

這是簡單的故事。現實生活要複雜得多。 SELECT可以有多個讀取點（並行計劃）。 SELECT和UPDATE都可以選擇訪問路徑，也就是說使用一個或多個二級索引來定位行。複雜查詢可能包含導致對錶進行多重查詢的運算符（例如連接）。 SELECT和UPDATE都可以執行書籤查找來獲取BLOB數據，這顯着改變了鎖定行爲。基數估計可能會導致SELECT以高粒度鎖定模式運行（例如，表級別共享鎖定）。 UPDATE可以觸發鎖升級，升級可能失敗或成功。 Choosing different access paths can lead to deadlock。 False lock contention can occur due to hash collisions。只有大約一個變量在這方面有發言權。而且我甚至沒有提到更高的隔離級別（可重複讀取，可序列化）。

也許你應該使用SNAPSHOT隔離並停止擔心這個問題？