6

私は、MySQL 5.6 がa (または他のテキストベースの型)の最初の 767 バイトのみをインデックス化できることを読んでいます。varchar私のスキーマ文字セットはutf-8であるため、各文字は最大 3 バイトに格納できます。767/3 = 255.66 であるため、これは、インデックスを作成する必要があるテキスト列の最大長が 255 文字であることを示しています。次のように、経験はこれを確認しているようです。

create table gaga (
    val varchar(255),
    index(val)
)   engine = InnoDB;

ただし、の定義をvalに変更するvarchar(256)と、「エラー コード: 1071。指定されたキーが長すぎます。キーの最大長は 767 バイトです」というメッセージが表示されます。

この時代では、255 文字という制限は非常に低いように思われますが、これは正しいですか? それがMySQLで索引付けされたより大きなテキストを取得する最良の方法は何ですか? (避けるべきですか? SHA を保存しますか? 別の種類のインデックスを使用しますか? 別のデータベース文字エンコーディングを使用しますか?)

4

1 に答える 1

7

この制限はばかげているように思えるかもしれませんが、このような長い varchar フィールドのインデックスが本当に必要かどうかを考えさせられます。767 バイトであっても、インデックスのサイズは非常に急速に大きくなり、大きなテーブル (最も有用な場合) の場合、ほとんどの場合、メモリに収まりません。

反対に、少なくとも私の経験では、長い varchar フィールドにインデックスを付ける必要がある唯一の頻繁なケースは、一意の制約でした。これらすべてのケースで、グループ ID と varchar フィールドの MD5 の複合インデックスで十分でした。唯一の問題は、大文字と小文字を区別しない照合 (アクセントのある文字とアクセントのない文字が等しいと見なされる) を模倣することですが、私の場合はすべてバイナリ照合を使用したため、問題はありませんでした。

アップデート。長い varchar をインデックス化するもう 1 つのよくあるケースは、順序付けです。この場合、私は通常、データ分布に応じて 5 ～ 15 文字のプレフィックスである別のインデックス付きソーター フィールドを定義します。私にとっては、めったに不正確な順序付けよりも、コンパクトなインデックスの方が望ましいです。

于 2013-04-30T19:47:49.347 に答える