0

SQL Serverが文字列を比較し、文字列内の検索を処理する方法(ステートメントなど)に関する情報はありますか?情報を大きな文字列として格納し、SQLサーバーを使用して行に対して一連の比較を行い、一致するものを判断することがどれほど効率的かを判断する方法があるかどうかを調べようとしています。これは潜在的に遅くなることはわかっていますが(情報の各文字列は2400文字の長さになります)、文字列の比較方法を説明する何かが必要です。そうすれば、その効率(または非効率)を示すことができます。

4

5 に答える 5

2

情報の各文字列は 2400 文字の長さになります

ちょうど2400?そこに固定幅のフィールドがありますか?時間を節約して、別々の列に分割するだけです。後で感謝します。

データが必要な場合は、テスト データベースをセットアップして、両方の方法で試してください。そうすれば、少なくともシステムに固有のデータが得られます

于 2009-04-21T19:03:47.010 に答える
0

SQL Server に適用できる全文検索インデックスがあり、検索エンジンなどによく使用されます。通常、フルテキスト インデックスでは、検索にブール論理演算子を使用できます。

于 2009-04-21T19:55:15.717 に答える
0

インデックスは長さ/幅が900バイトを超えることはできないため、インデックスを作成できないため、それらの検索は遅くなります

Joel Coehoornが提案することを行い、それを列に分割します

また、行ごとに 2400 文字のページごとに 3 行しか格納できないため、より多くのテーブルに分割することもできます。

于 2009-04-21T19:11:27.180 に答える
0

フルテキスト検索に関するMSDNの記事では、LIKE 述語が文字パターンを使用する方法について次のように説明されています。

LIKE と全文検索の比較

フルテキスト検索とは対照的に、LIKE Transact-SQL 述語は文字パターンに対してのみ機能します。また、LIKE 述語を使用して、フォーマットされたバイナリ データをクエリすることはできません。さらに、大量の非構造化テキスト データに対する LIKE クエリは、同じデータに対する同等のフルテキスト クエリよりもはるかに遅くなります。数百万行のテキスト データに対する LIKE クエリは、返されるまでに数分かかる場合があります。一方、フルテキスト クエリは、返される行数にもよりますが、同じデータに対して数秒以下しかかかりません。

于 2012-07-16T21:29:24.087 に答える
0

すでに述べたものへの追加情報です。大きな文字列を like でフィルタリングする必要がある場合、インデックスも使用されません (ただし、ワイルドカード % は検索文字列の最後にのみ使用されます)。そのため、like を避けて、フィルター処理が必要な部分を独自のフィールドで使用できるようにすることをお勧めします。

于 2009-04-21T21:37:00.700 に答える