2

テーブルがSiteありContent、データベースに含まれています。

各サイトは異なるクライアントによって運営されており、各サイトには独自のコンテンツがあります。

サイトのフロント エンドでは、コンテンツ テーブルで全文/フリーテキスト検索を使用して結果を返す検索ボックスを提供していますが、各サイトはデータベース内の他のサイトからではなく、それ自体からのみ結果を返すことができます。

ここでは、SQL Server クエリ オプティマイザーの動作が適切ではありません。コンテンツの少ないサイトのクエリを最適化すると、コンテンツの多いサイトのクエリはひどく実行され、タイムアウトが発生します。

これを修正するためにクエリの最後に追加できることは理解してOPTION(RECOMPILE)いますが、私の質問はこれです...

サイトごとにキャッシュ テーブルを作成して、各サイトのコンテンツを定期的にキャッシュし、パラメーターを使用する代わりに検索ストアド プロシージャでキャッシュ テーブルを検索できるようにする方がよいでしょうか?

キャッシュは、コンテンツが追加/変更されるたびにのみ更新/更新されます。

私の考えでは、これは....

a) 検索対象のテーブルのサイズを縮小して、正しいサイトのレコードのみが含まれるようにします

b) 全文検索で各サイトのコンテンツのより正確なインデックスを生成できるようにする

c) クエリ オプティマイザが各サイトの最適化されたクエリを個別にキャッシュできるようにする

これは正しいです？このようにするのは正しいですか？

4

2 に答える 2

2

「オプション（未知の最適化）」は試しましたか？これにより、予想される行数に関係なく、すべての入力に対して 1 つの汎用実行プランが生成されます。小規模なサイトでは以前より費用がかかりますが、大規模なサイトでは問題なく、小規模なサイトでも許容できるはずです。内部の仕組みについて詳しく説明したブログ投稿は次のとおりです: http://www.benjaminnevarez.com/2010/06/how-optimize-for-unknown-works/ .

于 2012-05-23T21:10:06.260 に答える
1

あなたは正しい質問をしています。それはトレードオフです。あなたの状況にとってどちらが良い/悪いかを決める必要があります。

頻繁にサイトを追加しますか? サイトごとに、合計で何行になると予想されますか? 一般に、SQL Server 2008 の全文検索は、数千万行まで問題なく実行できます。それ以上を期待する場合は、サイトを個々のテーブルに分割します。

複数のテーブルに分割した場合でも、特定の検索用語から返される数または単語によって、クエリ プランが大きく異なる可能性があることに注意してください。OPTION(RECOMPILE) の使用を検討することもできます。

各ルートの利点は次のとおりです。

シングルテーブル

  • サイトを追加するためのスキーマ変更はありません。
  • 管理が容易になります。
  • 複数のテーブルを処理するために個別のストアド プロシージャや動的 SQL について心配する必要はありません。

複数のテーブル

  • 小さいテーブルとインデックス (SiteId は必要ありません)。
  • カタログが小さいため、フルテキストのパフォーマンスが向上します。
  • データの分離が改善される可能性があります。
于 2012-05-24T21:35:54.760 に答える