フルテキスト インデックス付きの列を含む非常に大きなテーブルがあります。このテーブルを賢明に分割すると (私にとっては、賢明には日付で分割されます)、クエリが高速化されますか? または、クエリが 1 つのパーティションに制限されている場合でも、全文句は引き続きテーブル全体を検索しますか?
これまで見てきたことから、パーティション分割は役に立たないというのが答えだと思います。したがって、最良の選択肢は価値のある答えです。たとえば、日付範囲ごとにテーブルを作成し、[???] を実行することで簡単に維持できます。
編集: 非常に大きいのは現在 450 万行ですが、時間の経過とともに急速に増加します (明日は 2,000 万行になる可能性があるため、それを計画したいと思います)。ハードウェアに関しては、私はかなり無知です。クエリ全体がそうでなくても、全文クエリが多数の行を返す場合、クエリが遅いことは知っています。それがコンピューティングバウンドまたはIOバウンドであることを意味するのか、それとも伝えるのに十分な情報なのかはわかりません.
私はそうは思わない。
全文索引は、1 つの全文カタログに存在します。
これは、日付範囲に基づいてデータをデータ ファイル グループにパーティション分割し、ビューと制約を使用してクエリを正しいパーティションに送信するのとは大きく異なります。
私の考えは、フル テキスト カタログとインデックスが独自の LUN/ディスク セットにあることを確認することです。
GBN の言うとおりです。役に立ちません。
通常、ハードウェアの問題を解決するためにスキーマを変更することは避けることをお勧めします。FTS セットアップのベスト プラクティスに従うと、非常にうまくスケーリングできます。「非常に大きなテーブル」の意味と、それがどのようなハードウェアであるかを明確にすることができれば、おそらくより良い答えを出すことができます. たとえば、低速 RAID 5 で 6 ドライブを備えた 2-CPU 16GB RAM ボックス上の 100 万行テーブルですか、それとも RAID で 100 ドライブ SAN を備えた 4-CPU 64GB ボックス上の 1,000 万行テーブルですか? 10?