全站搜索的多站點CMS和SQL Server查詢優化器

我們在我們的數據庫中有表Site和Content。全站搜索的多站點CMS和SQL Server查詢優化器

每個網站由不同的客戶端運營，每個網站都有自己的內容。

在網站的前端，我們提供了一個搜索框，它在內容表上使用全文/自由文本搜索來返回結果，但每個網站只能從其自身返回結果，而不是從數據庫中的其他網站返回結果。

SQL Server查詢優化器在此表現不佳。如果它優化了內容很少的網站的查詢，那麼查詢會對導致超時的大量內容的網站表現可怕。

據我們瞭解，我們可以添加OPTION(RECOMPILE)來查詢，以解決這個問題的結束，但我的問題是這樣的......

它會更好，以創建緩存表中的每個網站，這樣的內容對每個網站可以定期緩存，並讓搜索存儲過程尋找一個緩存表，而不是使用參數？

只有在添加/更改內容時，緩存纔會更新/刷新。

我的想法是，這將....

a）減少表的大小被搜索到只包含記錄正確的站點

二）允許全文搜索，生成爲每個站點

三）允許查詢優化器緩存優化的查詢每個站點獨立

這是正確的內容更準確的指標？我以這種方式做對嗎？

來源

2012-05-11 Hades

請您提供一些關於這些表格的結構和內容的更多細節？ – swasheck

另外，由於FTS引擎已更改，請提供您正在使用的SQL Server版本。 – swasheck

SQL Server 2008網絡版。「網站」只是一個設置和識別表格，用於識別給定的網站並保存它的配置。 'Content'具有ID，圖像，標題，TeaserText，BodyText，CategoryID – Hades

你在問正確的問題。這是一個權衡。你必須決定哪種情況更好/更糟。

你會頻繁地添加網站嗎？你預計總共和每個站點有多少行？一般來說，SQL Server 2008全文搜索可以精確到數百萬行。如果你期望比這更多，我會把網站分割成單獨的表格。

請記住，即使您將數據拆分爲多個表格，由於從給定搜索項目返回的數字或單詞，您的查詢計劃仍可能會有很大差異。您可能仍然想要考慮使用OPTION（RECOMPILE）。

下面是每個路徑的一些優點：

單桌

沒有架構更改添加其他網站。
更容易管理。
不需要擔心單獨的存儲過程或動態SQL來處理多個表。

多個表

較小的表和索引（不需要SITEID）。
由於目錄較小，因此具有更好的全文性能。
潛在更好的數據分離。

來源

2012-05-24 21:35:54

你有沒有試過「選項（優化未知）」？這將爲您的所有輸入生成一個通用執行計劃，無論預計有多少行。對於比以前小的網站來說，它的成本會更高，但對於較大的網站來說應該是可以的，並且對於較小的網站來說仍然可以接受。以下是詳細介紹內部工作的博客文章：http://www.benjaminnevarez.com/2010/06/how-optimize-for-unknown-works/。

來源

2012-05-23 21:10:06 Zhenny

全站搜索的多站點CMS和SQL Server查詢優化器

回答

相關問題