6

行ごとに 1000 ～ 5000 文字のテキストを定期的に保持し、すべてのクエリで返され、LIKE %search% で頻繁に検索される "descr" varchar(15000) フィールドがあります (データベースは mysql 5.5 であり、フルテキスト インデックスです)利用できません）。入力されたテキストは研究データであるため、一意である必要はありませんが、検索可能である必要があります。

テーブルは、utf-8 エンコーディングの innodb です。行数は多くありません (30,000)。varchar の最大インデックス サイズは (255) ですが、列を検索すると、3000 文字の入力を含む行が正しく返されます。

私はインデックス作成について多くのことを読みましたが、最も関連性の高いのはMySQL: Large VARCHAR vs. TEXT? です。:

  • TEXT は、テーブルと一緒にテーブルの外に格納されます。
  • VARCHAR はインラインで格納され、サイズが適切で、データが頻繁に取得される場合ははるかに高速です。

理解の助けが必要です:

 1. What is the performance impact on retrieval (with 30,000 rows)
    going to a text field and     
 2. Is a varchar index workable for
    searching through 3000-5000 character fields? How is the search able
    to find strings with data longer than the 255 varchar index anyway?
    Or would you advise going with mediumtext?

ご意見ありがとうございます。

4

1 に答える 1

9

LIKE %search%まず、検索で使用する場合、その述語は BTREE インデックスを使用できないため、列にどのようにインデックスを付けるかは問題ではありません。VARCHAR と TEXT のどちらを選択しても、テーブル スキャンが実行されます。

次に、InnoDB が VARCHAR と TEXT を格納する方法に違いはありません。どちらも可変長文字列として扱われます。他の列と同じデータ ページに収まる場合は、収まります。それらが 1 ページに対して長すぎる場合 (または、各ページが少なくとも 2 行といくつかのヘッダー情報に収まる必要があるため、実際には 1 ページの半分よりわずかに少ない場合)、768 バイトのみがページに格納され、残りはの文字列がオーバーフロー ページに移動します。テーブルを use に宣言しない限りROW_FORMAT=DYNAMIC、その場合、ページに収まらない場合、すべての文字列がオーバーフロー ページに入ります。http://www.mysqlperformanceblog.com/2010/02/09/blob-storage-in-innodb/も参照してください。

私のプレゼンテーションFull Text Search Throwdownにも興味があるかもしれません。Sphinx Search など、他のコンパニオン テクノロジを比較します。

于 2013-10-26T00:05:03.320 に答える