ハッシュIDの非バイナリに対するMySQLバイナリ

はい。多くの場合、ハッシュダイジェストは16進数のASCII表現として保存されます。たとえば、「ハッシュ」という単語のMD5は次のとおりです。

0800fc577294c34e0b28ad2839435945

これは32文字のASCII文字列です。

しかし、MD5は実際には128ビットのバイナリハッシュ値を生成します。これはすべき 16進数ではなく、16バイトのみを2進値として格納する必要があります。したがって、バイナリ文字列を使用することで、ある程度のスペース効率を得ることができます。

CREATE TABLE test.foobar (
  id BINARY(16) NOT NULL PRIMARY KEY
);

INSERT INTO test.foobar (id) VALUES (UNHEX(MD5('hash')));

再。スペース効率よりもパフォーマンスに関心があるというコメント：

BINARYデータ型がCHARよりも高速になる理由はわかりません。

キャッシュバッファを効果的に使用する場合、半分の大きさであることがパフォーマンスの利点になる可能性があります。つまり、文字列が同じ値を16進数で格納するために必要なCHARの半分のサイズである場合、特定の量のキャッシュメモリは2倍の行に相当するBINARYデータを格納できます。同様に、その列のインデックスのキャッシュメモリは2倍の量を格納できます。

ランダムクエリでは、ディスクアクセスを必要とせずに、キャッシュされたデータまたはインデックスにアクセスする可能性が高くなるため、結果としてキャッシュがより効果的になります。通常、ボトルネックはディスクI / Oであるため、ほとんどのデータベースアプリケーションではキャッシュ効率が重要です。キャッシュメモリを使用してディスクI/Oの頻度を減らすことができれば、データ型を選択するよりもはるかに大きなメリットがあります。

BINARYに格納されているハッシュ文字列とBIGINTの違いについては、BIGINTを選択します。キャッシュ効率はさらに高くなり、64ビットプロセッサでは整数演算と比較が非常に高速になるはずです。

上記の主張を裏付ける測定値はありません。あるデータ型を別のデータ型よりも選択することの正味の利点は、データベースとアプリケーションのデータパターンとクエリの種類に大きく依存します。最も正確な答えを得るには、両方の解決策を試し、違いを測定する必要があります。

再。バイナリ文字列の比較は、大文字と小文字を区別しないデフォルトの文字列比較よりも高速であるという想定で、次のテストを試しました。

mysql> SELECT BENCHMARK(100000000, 'foo' = 'FOO');
1 row in set (5.13 sec)

mysql> SELECT BENCHMARK(100000000, 'foo' = BINARY 'FOO');
1 row in set (4.23 sec)

したがって、バイナリ文字列の比較では、大文字と小文字を区別しない文字列の比較よりも17.5％高速です。ただし、この式を1億回評価した後でも、合計の差は1秒未満であることに注意してください。速度の相対的な違いを測定することはできますが、速度の絶対的な違いは実際には重要ではありません。

繰り返しになります：

測定し、推測したり、推測したりしないでください。あなたの知識に基づいた推測は、多くの場合間違っています。変更を加えるたびに前後に測定するので、それがどれだけ役に立ったかがわかります。
時間と注意を払って、最大の見返りを得ることができます。
小さなものを汗を流さないでください。もちろん、わずかな違いが十分な反復で加算されますが、それらの反復を考えると、絶対的な利益が大きいパフォーマンスの改善が依然として望ましいです。