在查詢中使用過濾器和CONTAINSTABLE時的執行計劃不佳

我們有一個有趣的問題，我希望有人能夠幫助解決一些問題。在高層次上的問題如下：在查詢中使用過濾器和CONTAINSTABLE時的執行計劃不佳

下面的查詢快速執行（1秒）：

SELECT SA.* 
FROM cg.SEARCHSERVER_ACTYS AS SA 
JOIN CONTAINSTABLE(CG.SEARCHSERVER_ACTYS, NOTE, 'reports') AS T1 ON T1.[Key]=SA.UNIQUE_ID

，但如果我們添加了一個篩選的查詢，則需要大約2分鐘返回：

SELECT SA.* 
FROM cg.SEARCHSERVER_ACTYS AS SA 
JOIN CONTAINSTABLE(CG.SEARCHSERVER_ACTYS, NOTE, 'reports') AS T1 ON T1.[Key]=SA.UNIQUE_ID 
WHERE SA.CHG_DATE>'19 Feb 2010'

看着兩個查詢執行計劃，我可以看到，在第二種情況下有兩個地方有，它們是行的實際和估計數之間的巨大差異：

1）對於FulltextMatch表值函數，估計值約爲22,000行，實際值爲2900萬行（然後在連接前將其過濾爲1670行）和 2）對於索引查找全文索引，其中估計值爲1行，實際值爲13,000行

由於估計結果，優化器選擇使用嵌套循環連接（因爲它假定行數很少），因此計劃效率低下。

我們可以通過（a）參數化查詢並向查詢添加OPTION（OPTIMIZE FOR UNKNOWN）或（b）通過強制使用HASH JOIN來解決問題。在這兩種情況下，查詢都會在1秒內返回，估計似乎是合理的。

我的問題確實是'爲什麼這些估計值被用在表現不佳的案例中，因此非常不準確，可以採取哪些措施來改善它們'？

統計信息在此處使用的索引視圖上的索引是最新的。

任何幫助非常感謝。

來源

2010-04-16 Paul McLoughlin

據我所知，這是SQL Server版本的一個問題。該問題表現在SQL Server 2008中，沒有Service Pack。將數據庫恢復到具有SP1的計算機上，CU5給出了一個不同的（並且更加高效）的執行計劃。 – 2010-04-16 22:00:24

這裏的問題原來是SQL Server的版本。該問題表現爲SQL Server 2008（不包含Service Pack），並通過升級到SQL Server 2008 SP1（並添加了CU5）解決。由於我們沒有測試沒有安裝CU5，我無法確定修補程序是否附帶SP1或CU5。無論如何，問題都解決了。士氣？讓你的服務器保持最新狀態。

來源

2010-06-02 18:58:34

有趣。我有完全相同的問題，但我有最新版本的2008 R2。如果結果集很小，它似乎選擇了錯誤的執行計劃。添加OPTION（HASH JOIN）似乎可以解決這個問題，但我對這個問題肯定不夠了解。我擔心，如果結果集較大，我可能會不必要地放慢速度。它可能是統計數據有問題嗎？你怎麼看？ – 2010-08-27 11:40:37

如果有人仍在閱讀本文，我通過調用'sp_updatestats'來解決我的問題。統計顯然不同步。很明顯，真的。有可能你有同樣的問題，但可能升級SQL Server更新統計信息。 – 2010-11-24 14:38:33

也許你可以在有問題的列上添加一些統計信息 - 這將有助於SQL Server更好地估計行數及其內容。

目前涉及哪些統計或索引？

來源

2010-04-16 19:41:17 SqlRyan

當前正在使用的索引是：索引視圖上的聚集索引，它位於UNIQUE_ID列（正在掃描查找大於傳入日期的日期），然後是全文索引（對於this unique_id）在CHG_DATE列的索引視圖中存在一個索引，但似乎沒有被使用。 – 2010-04-16 20:01:24

我可以在這裏理解聚集索引的初始索引掃描，但我感到困惑的是全文索引的索引查找 - 這是估計（1行）和實際（13,000）使我最困惑的地方。 – 2010-04-16 20:10:44

在查詢中使用過濾器和CONTAINSTABLE時的執行計劃不佳

回答

相關問題