非常慢的SQL查詢

我遇到緩慢查詢的問題。考慮表tblVotes - 它有兩列 - VoterGuid，CandidateGuid。它擁有選民投給任何候選人的選票。非常慢的SQL查詢

有超過300萬行此表 - 與13000不同的選民投票時，約270萬考生不同。該表中的行總數目前爲650萬。

什麼我的查詢要達到的目的是讓 - 儘可能以最快和最高速高效的方式（我們使用的SQL Express） - 根據他們收到的票數排名前1000的候選人。

的代碼是：

SELECT CandidateGuid, COUNT(*) CountOfVotes 
FROM dbo.tblVotes 
GROUP BY CandidateGuid 
HAVING COUNT(*) > 1 
ORDER BY CountOfVotes DESC

...但是這需要一個scarily很長時間才能在SQL Express運行時，有一個非常完整的表。

任何人可以提出一個很好的方式來加快這得到它在快速的時間運行？ CandidateGuid被單獨編入索引 - 並且CandidateGuid + VoterGuid上有一個複合主鍵。

來源

2013-05-07 Jackfruit

我認爲你需要CountOfVotes上的額外索引，因爲你的排序是通過它來完成的，Count也會對它進行評估。 – DrCopyPaste 2013-05-07 14:30:57

CountOfVotes計算在這個查詢裏面，它不是一個永久性的可索引列嗎？ – Jackfruit 2013-05-07 14:36:14

哦，我的，它在這裏遲到我很抱歉:) – DrCopyPaste 2013-05-07 14:38:51

如果你有一個表只有兩列，這些兩個字段一個「正常」的指數不會幫助你多少，因爲它實際上是整個表的副本，只訂了。首先檢查執行計劃，如果您的索引正在使用。然後考慮將您的索引更改爲聚簇索引。

來源

2013-05-07 14:43:54

嘗試使用，而不是having子句頂N， - 就像這樣：

SELECT TOP 1000 CandidateGuid, COUNT(*) CountOfVotes 
FROM dbo.tblVotes 
GROUP BY CandidateGuid 
ORDER BY CountOfVotes DESC

來源

2013-05-07 15:00:58

詳細說明，這種方式'ORDER BY'可以丟棄不在前1000的條目。實際上，最初的'HAVING'是多餘的。由於這裏沒有加入，計數爲零的候選人將不會出現在結果中。 – 2013-05-07 16:06:04

引擎是否還需要爲每個組計算COUNT？ – 2013-05-07 16:36:17

我不知道如果SQL Server能夠使用綜合指數以加快此查詢，但如果是能夠這樣做，您需要將查詢表示爲SELECT CandidateGUID, COUNT(VoterGUID) FROM . . .以獲得優化。這是「安全的」，因爲您知道VoterGUID從不是NULL，因爲它是PRIMARY KEY的一部分。

如果您的複合主鍵被指定爲（CandidateGUID，VoterGUID），您不會在CandidateGUID上獲得單獨索引的任何額外好處 - 現有索引可用於優化單例索引可幫助的任何查詢

來源

2013-05-07 16:35:41

非常慢的SQL查詢

回答

相關問題