這個SELECT語句爲什麼會鎖定在SQL Server上？

SELECT * FROM MY_TABLE;

一個簡單的查詢，當我運行它，SQL Server Management Studio中掛起。

其他表和視圖工作正常。

這是什麼原因造成的？我以前運行過UPDATE語句時有鎖，並且我知道如何處理這些語句。但是什麼可能導致SELECT鎖定？

我已經運行「所有阻塞事務」報告，它說沒有。

這可能不是被鎖定了選擇，但畢竟是編輯（UDPATE /刪除/插入）的表中的一些其他的過程，導致了鎖。

您可以通過在SQL Server上運行exec sp_who2來查看哪個進程被阻止。

另外，如果你是OK與髒讀，你可以做兩件事情

SELECT * FROM Table WITH (NOLOCK)

SET Transaction Isolation Level Read Uncommitted 
SELECT * FROM Table

2009-11-18 14:02:14

exec sp_who2給了我一個正在進行的ALTER INDEX。似乎是罪魁禍首。謝謝。 – JosephStyons 2009-11-18 14:14:59

使用此：

SELECT * FROM MY_TABLE with (NOLOCK)

2009-11-18 14:01:29 Mikhail

這是有效的，但我怎麼知道是誰造成了鎖？ – JosephStyons 2009-11-18 14:03:54

查看來自BradC的答案：某些其他進程在表上鎖定了一個鎖，從而阻止您的選擇直到鎖被釋放。 – Mikhail 2009-11-18 14:05:16

兩種可能性之一：

2009-11-18 14:02:42 BradC

否＃1。是的＃2但是誰/什麼？ – JosephStyons 2009-11-18 14:04:30

@BradC＃1是500m意味着5億，或者是別的。 – robert 2013-05-26 15:40:38

@robert，是的，我的意思是5億，或者其他一些荒唐的數字。 – BradC 2013-05-28 15:57:30

如果還有很多其他活動正在進行，其他的可能會導致鎖定，並且您的SELECT可能是死鎖受害者。如果您運行下面的

SELECT * FROM my_table WITH(nolock)

你告訴你是OK閱讀髒（uncomitted）數據的數據庫，並引起其他活動的鎖可以忽略。運行時，即腳本/存儲過程運行（或失敗 -

另外，如果像這樣的查詢導致管理工作室掛，你的表可能會使用一些優化

2009-11-18 14:04:17

MY_TABLE可以通過一些未提交的事務也鎖定了）在另一個MSMM窗口中。

2009-11-18 14:14:32

回答