Oui. Souvent, un résumé de hachage est stocké sous la forme d'une représentation ASCII de chiffres hexadécimaux, par exemple MD5 du mot "hachage" est :
0800fc577294c34e0b28ad2839435945
Il s'agit d'une chaîne ASCII de 32 caractères.
Mais MD5 produit vraiment une valeur de hachage binaire de 128 bits. Cela devrait ne nécessitent que 16 octets pour être stockés sous forme de valeurs binaires au lieu de chiffres hexadécimaux. Vous pouvez donc gagner en efficacité d'espace en utilisant des chaînes binaires.
CREATE TABLE test.foobar (
id BINARY(16) NOT NULL PRIMARY KEY
);
INSERT INTO test.foobar (id) VALUES (UNHEX(MD5('hash')));
Concernant. vos commentaires selon lesquels vous êtes plus préoccupé par les performances que par l'efficacité de l'espace :
Je ne connais aucune raison pour laquelle le type de données BINARY serait plus rapide que CHAR.
Être deux fois moins volumineux peut être un avantage pour les performances si vous utilisez efficacement les tampons de cache. Autrement dit, une quantité donnée de mémoire cache peut stocker deux fois plus de lignes de données BINARY si la chaîne est la moitié de la taille du CHAR nécessaire pour stocker la même valeur en hexadécimal. De même, la mémoire cache de l'index sur cette colonne peut en stocker deux fois plus.
Le résultat est un cache plus efficace, car une requête aléatoire a plus de chances d'atteindre les données ou l'index mis en cache, au lieu de nécessiter un accès au disque. L'efficacité du cache est importante pour la plupart des applications de base de données, car le goulot d'étranglement est généralement l'E/S disque. Si vous pouvez utiliser la mémoire cache pour réduire la fréquence des E/S de disque, c'est beaucoup plus rentable que le choix entre un type de données ou un autre.
En ce qui concerne la différence entre une chaîne de hachage stockée en BINARY et un BIGINT, je choisirais BIGINT. L'efficacité du cache sera encore plus grande, et également sur les processeurs 64 bits, l'arithmétique et les comparaisons d'entiers devraient être très rapides.
Je n'ai pas de mesures pour étayer les affirmations ci-dessus. L'avantage net de choisir un type de données plutôt qu'un autre dépend beaucoup des modèles de données et des types de requêtes dans votre base de données et votre application. Pour obtenir la réponse la plus précise, vous devez essayer les deux solutions et mesurer la différence.
Concernant. votre supposition que la comparaison de chaînes binaires est plus rapide que la comparaison de chaînes insensible à la casse par défaut, j'ai essayé le test suivant :
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)
Ainsi, la comparaison de chaînes binaires est 17,5 % plus rapide que la comparaison de chaînes insensibles à la casse. Mais notez qu'après avoir évalué cette expression 100 millions de fois, la différence totale est toujours inférieure à 1 seconde. Bien que nous puissions mesurer la différence relative de vitesse, la différence absolue de vitesse est vraiment insignifiante.
Je vais donc réitérer :
- Mesurez, ne devinez pas ou ne supposez pas. Vos suppositions éclairées seront erronées la plupart du temps. Mesurez avant et après chaque changement que vous apportez, afin de savoir à quel point cela a aidé.
- Investissez votre temps et votre attention là où vous en aurez le plus pour votre argent.
- Ne transpirez pas les petites choses. Bien sûr, une petite différence s'additionne avec suffisamment d'itérations, mais compte tenu de ces itérations, une amélioration des performances avec un avantage absolu plus important est toujours préférable.
