引用主鍵時SQL查詢速度極慢

我有一個包含大約800萬條記錄的MS SQL表。在「ID」列上有一個主鍵（聚簇索引只有0.8％的分段）。當我運行貌似任何引用ID列的查詢時，查詢花費很長時間（實際上最終導致應用程序崩潰）。這包括簡單的查詢，如「SELECT * FROM table WHERE ID = 2020」。相比之下，不引用ID的查詢（例如「SELECT TOP 100 * from table」）就沒有問題。引用主鍵時SQL查詢速度極慢

任何想法？

來源

2010-09-01 alpheus

「非常長」是什麼意思？ 1秒？ 20秒？ – 2010-09-01 04:09:02

超過10分鐘。 – alpheus 2010-09-01 04:13:25

我不明白爲什麼 - 更新統計數據的bigint，PK = Clustered Index應該和它一樣好。沒有別的鎖定ID = 2020？嘗試SELECT * FROM表（NOLOCK）WHERE ID = 2020。如果一切都失敗了，請嘗試刪除聚集索引（和所有NC指數）並重新創建。 – StuartLC 2010-09-01 04:16:02

如果查詢花費10分鐘（！？！）你已經得到的東西嚴重錯誤。即使是800萬條記錄的表掃描也只需要一兩秒。我會檢查事件日誌中是否存在即將發生的硬件故障，或者嘗試將數據庫移至其他服務器以查看是否存在其他硬件故障。

來源

2010-09-01 04:19:49

如果列中存在無類型的XML blob會怎麼樣？ – Spence 2010-09-01 05:26:54

ID是一個GUID的機會嗎？ SQL Server在GUID列上產生了散列問題，這使得它們在索引中表現不佳。

準確查詢並從Sql Server Management Studio中獲取「預計執行計劃」。如果您查詢觸發表掃描（它不應該），那麼這將解釋時間。也許這個計劃可能會告訴你還有什麼事情發生。

我假設你已經重建了索引（根據你的0.8％碎片評論）。

來源

2010-09-01 04:02:33 Spence

我會試一試。 ID是一個bigint。執行計劃 – alpheus 2010-09-01 04:04:55

我懷疑查詢是在進行表掃描（或者，至少是對一個非常大或過時的統計數據索引進行索引掃描）。生成一個估計的執行計劃（SSMS中的Control-L）或讓SQL Server返回它實際使用的執行計劃，因爲它有時是不同的（Control-M啓用它，然後正常運行查詢 - 它會在您的旁邊創建一個新選項卡結果）。

一旦你有執行計劃，搜索表掃描或索引掃描，這很可能是你的緩慢的來源。「估計的執行計劃」甚至可能會推薦和索引，以幫助查詢更快地返回 - 新版本的SQL Server/SSMS包含此功能。

雖然我懷疑你不會找到任何有趣的東西 - 你的查詢只是一個單一的步驟 - 這裏的一對讀取執行計劃的快速介紹：http://sqlserverpedia.com/wiki/Examining_Query_Execution_Plans

來源

2010-09-01 04:16:22 SqlRyan

是個好主意。它可能引用索引問題或數據頁面問題。 Alpheus，你可以把你的查詢執行計劃嗎？ – 2010-09-01 06:47:03

我檢查的統計數據，如果你已經檢查碎片

他們被禁用或沒有更新？

他們快速的檢查方法是使用STATS_DATE

來源

2010-09-01 04:18:07 gbn

exec sp_updatestats – Spence 2010-09-01 04:18:57

@Spence：如果他們被禁用或從未創建，這將無法正常工作。 – gbn 2010-09-01 05:38:34

我想如果你使用的是默認的閱讀水平，並且你有一個很長的運行更新，你可能會遇到死鎖？這肯定也會造成這種情況。

來源

2010-09-01 06:17:45 Spence

引用主鍵時SQL查詢速度極慢

回答

相關問題