SQL 2005 ボックスでフルテキスト カタログを作成しましたが、再構築プロセスが完了した後、実行速度が非常に遅くなります。ユーザーがタイムアウト エラーにならないように、ハック (つまり、try...catch{do again}) を実装しました。これは私の中で気分が悪くなります。後続のすべてのクエリは非常に高速です。
この問題を経験した人はいますか?解決策はありますか? ありがとう!
PS はい、Google で何度も検索しました。左手でも。
SQL 2005 ボックスでフルテキスト カタログを作成しましたが、再構築プロセスが完了した後、実行速度が非常に遅くなります。ユーザーがタイムアウト エラーにならないように、ハック (つまり、try...catch{do again}) を実装しました。これは私の中で気分が悪くなります。後続のすべてのクエリは非常に高速です。
この問題を経験した人はいますか?解決策はありますか? ありがとう!
PS はい、Google で何度も検索しました。左手でも。
また、私たちが経験したこの Sql Server の「機能」が原因である可能性もあります。
インターネットにアクセスできないサーバー上で実行されている SQL Server 2005 のインスタンスでフルテキスト クエリを実行すると、45 秒の遅延が発生する場合があります。
これはあなたの質問に対する直接的な回答ではないかもしれませんが、mssql の全文検索はスタックオーバーフロー ポッドキャスト シリーズで取り上げられており、結論としては、それは最善の方法ではありません :)
したがって、サードパーティのライブラリに変更できる場合は、jeff & co. で使用されている Apache Lucene ライブラリを試すことができます。Java バージョンはhttp://lucene.apache.org/java/docs/で入手でき、.net ポートはhttp://incubator.apache.org/lucene.net/で入手できます。
Lucene.Netの提案を2番目にしています。私は以前、全文検索とSQLを使用してある種の「検索エンジン」を構築しようとしました。検索条件が複雑になり、クエリがタイムアウトすることがよくある場合、これは常に問題でした。私の新しいサイトでは、Lucene.Netプロジェクトを使用して検索エンジンを構築しました。これは非常にうまく機能し、SQLFTSよりもはるかに高速です。
フルテキスト インデックスが作成された各テーブルで「バックグラウンド updateindex の設定」と「変更追跡の開始」 (各単語の間にアンダースコアが必要) を行うことで、インデックスを完全に再構築する必要がなくなります。
これにより、SQL サーバーは、必要な場合にのみ変更を加えてインデックスを更新できます。インデックスが再構築されていないため、問題が解決する場合があります。
私もこれを持っていました。最初のヒットは非常に遅く、残りは高速です。あらゆる種類を試しましたが、解決できませんでした。
これに対する答えを知りたいです。