在SSRS Report Builder中查找的性能影響

Question

我最近遇到了瓶頸情況，如果我在報表內部保留當前版本的查詢（在報表生成器SSRS 2008中設計），它將生成最多15次的加載時間具有特定參數的報告的分鐘數。此JOIN表示我加入到非索引列的主查詢的子查詢。我們稱這個子查詢爲「單位」。

如果我刪除了「單位」從SQL查詢中的連接，並將其設置爲一個單獨的數據集的報告裏面，使用SSRS查找功能（同SQL的JOIN）將它鏈接到主數據設置（查詢），報告運行平穩，不到一分鐘（約3至5毫秒）。

請記住，當單獨運行時，對於之前花費15分鐘的相同參數運行的子查詢分別運行時間不到5毫秒，但當它連接到主查詢時會導致嚴重的性能問題。

做這種類型的分離有明顯的好處，還是應該進一步調查如何改進查詢？使用查找與提高當前查詢性能的性能優勢/缺點是什麼？

我的擔憂是這是一種情境改善，這不代表長期的解決方案。過去我使用這種替代方法來避免調整查詢，但它並未適得其反，但我並不完全瞭解使用此解決方法的性能影響。

謝謝， 拉杜。

Answer 1

有很多事情可能會導致性能問題，但這裏有一些簡單的事情可能使數據集以極小的努力重新加速。

1.參數嗅探

你提到具體參數，如果你的意思是，查詢只與某些參數表現不好，與其他參數表現良好，並假設數據的大小呢根據這些參數沒有顯着變化，那麼它可能是一個參數嗅探問題。這是由基於一組參數生成的查詢計劃造成的，這些參數不適合其他參數。證明這一點的最簡單方法是簡單地將option (recompile)添加到查詢的末尾。這不是一個永久修復，但它會強制生成一個新的查詢計劃。如果你看到即時改善，那麼參數嗅探是最常見的原因。

2.重構數據集查詢

另一種選擇是重新設計你的查詢。我不知道你查詢的樣子，但如果我們將根據您發佈的信息，一個簡單的例子...

如果查詢看起來像..

SELECT * FROM tableA a 
    JOIN (SELECT * FROM tableB WHERE someValue=someOtherValue) b 
     ON a.FieldA = b.FieldB 

，那麼你可以重構它通過將子查詢到一個臨時表，並加入到，像

SELECT * 
    INTO #t 
    FROM tableB WHERE someValue=someOtherValue 

SELECT * FROM tableA a 
    JOIN #t b 
     ON a.FieldA = b.FieldB 

這種方法是我經常帶它可以避開正是這些類型的性能問題。