Ya. Seringkali hash digest disimpan sebagai representasi ASCII dari digit hex, misalnya MD5 dari kata 'hash' adalah:
0800fc577294c34e0b28ad2839435945
Ini adalah string ASCII 32 karakter.
Tetapi MD5 benar-benar menghasilkan nilai hash biner 128-bit. Ini harus hanya membutuhkan 16 byte untuk disimpan sebagai nilai biner, bukan digit hex. Jadi, Anda bisa mendapatkan efisiensi ruang dengan menggunakan string biner.
CREATE TABLE test.foobar (
id BINARY(16) NOT NULL PRIMARY KEY
);
INSERT INTO test.foobar (id) VALUES (UNHEX(MD5('hash')));
Ulang. komentar Anda bahwa Anda lebih mementingkan kinerja daripada efisiensi ruang:
Saya tidak tahu alasan apa pun bahwa tipe data BINARY akan lebih cepat daripada CHAR.
Menjadi setengah besar dapat menjadi keuntungan untuk kinerja jika Anda menggunakan buffer cache secara efektif. Artinya, sejumlah memori cache yang diberikan dapat menyimpan data BINARY dua kali lebih banyak jika string berukuran setengah dari CHAR yang diperlukan untuk menyimpan nilai yang sama dalam hex. Demikian juga memori cache untuk indeks pada kolom tersebut dapat menyimpan dua kali lebih banyak.
Hasilnya adalah cache yang lebih efektif, karena kueri acak memiliki peluang lebih besar untuk mengenai data atau indeks yang di-cache, daripada memerlukan akses disk. Efisiensi cache penting untuk sebagian besar aplikasi database, karena biasanya hambatannya adalah I/O disk. Jika Anda dapat menggunakan memori cache untuk mengurangi frekuensi I/O disk, itu jauh lebih mahal daripada pilihan antara satu tipe data atau lainnya.
Adapun perbedaan antara string hash yang disimpan dalam BINARY versus BIGINT, saya akan memilih BIGINT. Efisiensi cache akan lebih besar, dan juga pada prosesor 64-bit aritmatika integer dan perbandingan harus sangat cepat.
Saya tidak memiliki ukuran untuk mendukung klaim di atas. Manfaat bersih dari memilih satu tipe data di atas yang lain sangat bergantung pada pola data dan tipe kueri dalam database dan aplikasi Anda. Untuk mendapatkan jawaban yang paling tepat, Anda harus mencoba kedua solusi tersebut dan mengukur perbedaannya.
Ulang. anggapan Anda bahwa perbandingan string biner lebih cepat daripada perbandingan string case-insensitive default, saya mencoba tes berikut:
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)
Jadi perbandingan string biner 17,5% lebih cepat daripada perbandingan string case-insensitive. Tetapi perhatikan bahwa setelah mengevaluasi ekspresi ini 100 juta kali, perbedaan totalnya masih kurang dari 1 detik. Meskipun kita dapat mengukur perbedaan relatif dalam kecepatan, perbedaan mutlak dalam kecepatan benar-benar tidak signifikan.
Jadi saya tegaskan lagi:
- Ukur, jangan menebak atau mengira. Tebakan Anda yang berpendidikan akan sering salah. Ukur sebelum dan sesudah setiap perubahan yang Anda buat, sehingga Anda tahu seberapa banyak itu membantu.
- Investasikan waktu dan perhatian Anda untuk mendapatkan hasil maksimal.
- Jangan memusingkan hal-hal kecil. Tentu saja, perbedaan kecil bertambah dengan iterasi yang cukup, tetapi dengan iterasi tersebut, peningkatan kinerja dengan manfaat absolut yang lebih besar masih lebih disukai.
