上記の定義と、以下のこの回答の冗長なモノローグから、次の改訂をお勧めします。
CREATE TABLE IF NOT EXISTS `bestillinger` (
`id` INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
`bestilling` TEXT NOT NULL,
`hashcode` CHAR(32) AS (MD5(bestilling)),
`accepted` VARCHAR(255) DEFAULT NULL,
UNIQUE KEY `id_bestilling` (hashcode,bestilling(333))
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
MySQL に固有の、単一列のインデックス キーのデフォルトの最大長は1000 バイトです ( innodb_large_prefix が設定されていない限り、 InnoDB テーブルの場合は 767 バイト)。同じ長さ制限が、すべてのインデックス キー プレフィックスに適用されます (CHAR、VARCHAR、TEXT の場合は最初の N 文字、BINARY、VARBINARY、BLOB の場合は最初の N バイト)。文字とバイトの違いに注意してください。UTF-8 文字セットと各文字の最大 3 バイトを想定すると、TEXT または VARCHAR 列で333 文字を超える列プレフィックス インデックスを使用すると、この制限に達する可能性があります。実際には、333 が私にとって良い最大値になる傾向があります。
同様に SQL Serverでは、すべてのインデックス キー列の最大合計サイズに 900 バイトの制限があります。
しかし、それは TEXT の最初の文字のみをキーとして使用するため、明らかな衝突が差し迫っています。
受け入れられた回答では、提案はFULLTEXT indexを使用することです。FULLTEXT インデックスはテキスト検索用に特別に設計されており、列レコードのボキャブラリ全体で N グラムを維持し、結果のベクトルを格納するため、INSERT/DELETE のパフォーマンスはあまり良くありません。これは、すべての操作が where 句でテキスト検索関数を使用する場合に機能しますが、一意のインデックスでは機能しません。「id」には主キーと一意のキーの両方が定義されていますが、これは冗長に見えるか、意図を見逃しています。
代わりに、計算されたハッシュを提案します。ハッシュとの衝突が発生する可能性 (Birthday Paradox) があることを指摘するのは正しいでしょう。そのため、UNIQUE インデックスだけでは十分ではありません。上記のように、列プレフィックス インデックスと組み合わせて、一意性を信頼できるようにします。
ID 列の意図は、他のテーブルからの適切な外部キー参照を許可することです。その通りですが、それがこのテーブルのより有用な主キーになります。同様に、int(11) は、基になる値ではなく、列の表示幅を参照します。'id' にも unsigned auto_increment を付けて、より多くのユーザーに対してその役割を明確にしました。
そして、それが上記の提案された設計につながります。