3

次のMYSQLステートメントには0.577251秒かかります。

SELECT synonym_group FROM synonym WHERE name LIKE '%ak%'

名前はvarchar（250）フィールドです。シノニムデータベーステーブルには現在356,187レ​​コードがあります。データ：21MB。インデックス：23MB。合計サイズ：45MB。行あたりのバイト数：67。

では、0.577251秒は妥当な時間ですか？そうでない場合は、何をし、何をすべきですか？私はこのタイプの質問に関するいくつかのスレッドを読みました、そして私が見ることができる主な解決策はスフィンクスのようなものを使うことです。

真実は、私のテーブルのいくつかのフィールドはおそらく無関係であるということです。たとえば、不要なフィールドを削除して1行あたりのバイト数を半分にすると、検索が2倍速くなりますか？

前もって感謝します。

4

3 に答える 3

5

LIKEで始まる演算子を使用する場合%、選択にインデックスは使用されません。

だから、はい、その時間は正常です。

于 2012-04-15T19:51:32.440 に答える
4

が単語の場合ak、FULLTEXT インデックスが機能します (最小単語長を調整する場合は、以下を参照してください)。

したがって、FULLTEXT インデックスで「ak」を検索すると、次のように一致します。

  • 「これはそれだ」
  • 'AK'
  • 'AK。なんでもいい。'
  • 'なんでもいい。AK.'

ただし、これは一致しません。

  • 「バク」
  • 「AKT」

一致させるには、単語の境界が必要です。

FULLTEXT 検索のデフォルトの最小単語長は 4 文字です。したがって、'ak' は短すぎるため、まだ FULLTEXT 検索を実行できませんでした。最小単語長の設定を下げることもできますが、「the」、「and」、および FULLTEXT インデックスを乱雑にしたくない他のすべての 3 文字以下の単語で終わることになります。

LIKE で検索することが唯一の実行可能なオプションかもしれません。先頭のワイルドカード ( '%ak') を使用すると、MySQL はインデックスを使用してレコードを見つけることができません。すべての行をスキャンする必要があります。それでも、カバリング インデックスがある場合は、インデックスを使用してスキャンします。

したがって、クエリの場合：

SELECT synonym_group FROM synonym WHERE name LIKE '%ak%'

に複数列、カバー、インデックスがある(name, synonym_group)場合、実際にはインデックスを使用してクエリに答えますが、従来の意味ではありません。MySQL はインデックスをスキャンします。これは通常、実際のテーブル データをスキャンするよりも高速です (テーブル スキャン)。さらに、理想的なシステムには、すべてのインデックスを RAM に格納するのに十分な RAM があるため、ディスクではなくメモリをスキャンするだけです。

したがって、カバリング インデックスでは、行のサイズは影響しません。

カバー インデックスがないと、ディスクをさらに移動する必要があるため、行のサイズがスキャン速度に影響します。

テーブルスキャンを実行することになった場合は、テーブルを最適化して、できれば固定長の行 (VARCHAR ではなく CHAR) を使用する必要があります。

于 2012-04-15T21:45:15.160 に答える
3

juergen d が言及しているように、最初に % を使用した検索ではインデックスを使用できず、テーブル全体をスキャンする必要があります (テーブルのサイズが大きくなるにつれて悪化するだけです)。実際の CPU ドレインがすべての行の文字列を循環しているため、列の数を減らしても役に立たない可能性があります。

この場合、全文検索とインデックスの使用を検討する必要があります: http://dev.mysql.com/doc/refman/5.0/en/fulltext-search.html

于 2012-04-15T19:58:22.437 に答える