8 300 000行のような巨大なテーブルがあります（編集も削除もされません）。
私の最初の列は似たようなものP300-4312B_X16_Sで、エントリは一意ではないため、このフィールドでは通常のINDEXを使用します。
ただし、MySQLはvarcharの代わりにバイナリフィールドを使用する方がはるかに高速であるためBINARY(16)、データの保存に使用して、MD5でINDEXをエンコードします。
今朝、初めてCRC32を使い始めましたが、CRC32は8文字の16進文字列として出力できることがわかりました。
私の質問：MD5の代わりにCRC32を使用すると、より高速になります。ただし、CRC32が実行されると、たとえば2 000 000の一意の値が実行されると、結果は一意になります。または、2つの異なる文字列に対して2回同じ文字列が使用される場合がありますか？結果は、MD5のように32（128b）ではなく、わずか8文字（32b）の長さなので、お願いします。
ありがとう。
予想される衝突の数は、可能なチェック値の数に対するペアの数です。したがって、2,000,000の値の場合、（2000000 * 1999999）/ 2ペアがあり、これは約2x1012です。32ビットCRCの場合、予想される衝突の数は2 32を超え、つまり466です。したがって、この場合、衝突が発生することが基本的に保証されます。
128ビットのMD5チェック値の場合、予想される衝突の数は約6x10-27です。期待値の値が小さい場合、それは1回の衝突の確率でもあります。
衝突の可能性が非常に低いことが重要な場合は、CRC-32以外のものを選択する必要があります。
ただし、MD5のオーバーヘッドは必要ありません。この場合、その暗号強度はアプリケーションにとって重要ではありません。悪意のある人が別のエントリと同じチェック値を持つエントリを作成する方法を見つけることができるかどうかは、実際には気にしません。したがって、その目的のために設計された64ビットの非暗号化ハッシュを使用できます。これにより、実行速度が大幅に向上し、値が2,000,000の場合に衝突の確率が10-7になります。または、128ビットの非暗号化ハッシュを使用して、MD5の場合と同じ確率を取得できますが、はるかに高速です。CityHashファミリーのハッシュアルゴリズムを見てください。
ただし、すべての場合において、衝突の確率はゼロではないことに注意してください。コードへの衝突の結果を考慮する必要があります。