0

テキスト列に基づいて完全一致フィルターを実行することは、キーに基づいて行のセットを取得し、プログラミング言語を使用してフィルター処理するよりも概念的に遅いですか？

例えば：

select columns from table where textcolumn='exactphrase';

vs

select columns from table where key='key';

for (results : resultset) { 
      if (resulsts.getString(textcolumn).equals(exactphrase)) { ... } }

基本的に、MySQL（Innodb）がテキスト列のフィルタリングをどのように処理するか、およびパフォーマンスの落とし穴（ある場合）について知りたいです。

4

2 に答える 2

3

たぶん、でも私はそれを疑っています。

一連の制約内では、すべての単一のテーブル、データベース、およびクエリが異なります。単一のサーバーでのクエリの「迅速性」は、（他の多くのことの中でも）次のことに依存する可能性があります。

  • インデックス
  • 列のカーディナリティ-値の数に対する個別の値の数。
  • 列の幅
  • テーブル内のレコードの数
  • クエリで返されるバイト数。
  • 他の誰かがデータベース/サーバーを使用しているかどうか

一般的に言えば、SQLですべてを実行する方が常に高速ですが、これは上記のすべてに依存するため、確実ではありません。

確認する唯一の方法は、自分で試してみることです。その後、問題が発生した場合は、いつでもクエリ、説明プラン、テーブルとインデックスの定義を投稿でき、誰かが助けてくれるかもしれません。

于 2012-11-27T19:36:01.957 に答える
1

tldr; レコードを「検索」するためのパフォーマンスの違いはありません。

（インデックス付きの）PKが使用されているため、最大で1つのレコードが返されます。サーバーは、PKのカーディナリティが1-1であるためにインデックスが作成されていない場合でも、テキスト列でテーブルスキャンを実行しないほどスマートです。（クエリプランナーは賢いです。）

違いは次のとおりです。

  1. サーバーは「役に立たない」レコードをクライアントに返す可能性があります。これにより、少量の帯域幅1が無駄になる可能性があります（とにかくテスト以外のテキストが必要ない場合は少し無駄になります）が、さらに重要なことに、クエリのセマンティクスが混乱します。

  2. サーバーはさまざまな照合モードをサポートしています。そのため、サーバーでは大文字と小文字が区別されず（たとえば）、クライアント側のフィルターとはわずかに異なる結果になる可能性があります。

1非常に退化したケースを想像することもできますが、これは、明示的な使用/パフォーマンスのケースがない場合は「同等の時間」と見なす必要があります。ただし、IMOHOは、それ以上の理由なしにクライアント側でこれを行うのはまだずさんです。

于 2012-11-27T19:34:31.970 に答える