性能使用DISTINCT COUNT

Question

我正在運行SQL Server 2012的

我有一個查詢，當條紋到它的最基本的形式是這樣的：

SELECT COUNT(DISTINCT fullAddress) as quickCount 
FROM leads 
WHERE yearID >=12 AND yearID <=21 

引線表中有大約149萬條記錄中它。 leadID上有一個聚集索引，而非聚集索引是YearID上的索引，並且包含fullAddress。

該查詢，因爲它是需要大約40秒運行。我意識到這並不壞，但在這種情況下，速度不夠快。

我看着執行計劃，並從我可以告訴成本的約60％是重複計數。

當我運行不重複計數這樣相同的查詢：

SELECT COUNT(*) as quickCount 
FROM leads 
WHERE yearID >=12 AND yearID <=21 

只需1秒運行。

不幸的是，我需要完全不同的地址的數量。所以我想弄清楚是否有任何事情可以使第一個查詢運行得更快。

下面是執行計劃的兩個查詢的截圖：

這裏是一個鏈接，看到它更大 - http://www.sequenzia.com/execPlan.jpg

從我可以告訴我的主要問題是不同的排序（52％）。

對此的任何幫助或反饋將是偉大的。

謝謝！

UPDATE

我把蒂洛的意見，並應用該指標：

CREATE INDEX IDX_X ON LEADS(FULLADDRESS, YEARID); 

我居然在他們每個人創造了完全相同的1萬條記錄2個新的測試表。我將相同的原始索引應用於兩者，然後將上述索引應用到一個。現在，當我比較同一個執行計劃中的2個表時，具有上述索引的表格比48％到52％稍好。這裏是新的執行計劃 - http://www.sequenzia.com/execPlan2.jpg

這有助於一些，但我真的需要更多的性能。那裏有其他想法嗎？

Answer 1

有一件事要嘗試擺脫排序，通過在fullAddress（也包括yearID列，以便您可以滿足where子句）上訂購索引。

CREATE INDEX IDX_X ON LEADS(FULLADDRESS, YEARID); 

這樣，你應該得到一個快速全索引掃描（可能比索引範圍掃描你有非重複計數仍然較慢，但希望比你40多歲的排序更快）。

但爲什麼它要這麼快？這不是你需要一直做的事，對吧？如果這是一個公共網站，我會想，你可以放棄一個稍微過時的緩存結果。

Answer 2

如果不更新此表很多時候你可以看一下創建與查詢索引視圖您正在運行 http://msdn.microsoft.com/en-us/library/aa933148(v=sql.80).aspx