Sí. A menudo, un resumen hash se almacena como la representación ASCII de dígitos hexadecimales, por ejemplo, MD5 de la palabra 'hash' es:
0800fc577294c34e0b28ad2839435945
Esta es una cadena ASCII de 32 caracteres.
Pero MD5 realmente produce un valor hash binario de 128 bits. Esto debería requieren que solo se almacenen 16 bytes como valores binarios en lugar de dígitos hexadecimales. Por lo tanto, puede obtener algo de eficiencia de espacio mediante el uso de cadenas binarias.
CREATE TABLE test.foobar (
id BINARY(16) NOT NULL PRIMARY KEY
);
INSERT INTO test.foobar (id) VALUES (UNHEX(MD5('hash')));
Re. sus comentarios de que le preocupa más el rendimiento que la eficiencia del espacio:
No conozco ninguna razón por la que el tipo de datos BINARY sea más rápido que CHAR.
Ser la mitad de grande puede ser una ventaja para el rendimiento si usa los búferes de caché de manera efectiva. Es decir, una cantidad determinada de memoria caché puede almacenar el doble de filas de datos BINARIOS si la cadena tiene la mitad del tamaño del CARÁCTER necesario para almacenar el mismo valor en hexadecimal. Asimismo, la memoria caché para el índice de esa columna puede almacenar el doble.
El resultado es una memoria caché más eficaz, porque una consulta aleatoria tiene una mayor probabilidad de acceder a los datos o índices almacenados en la memoria caché, en lugar de requerir un acceso al disco. La eficiencia de la memoria caché es importante para la mayoría de las aplicaciones de bases de datos porque, por lo general, el cuello de botella es la E/S del disco. Si puede usar la memoria caché para reducir la frecuencia de E/S del disco, es mucho más rentable que elegir entre un tipo de datos u otro.
En cuanto a la diferencia entre una cadena hash almacenada en BINARIO y BIGINT, elegiría BIGINT. La eficiencia de la memoria caché será aún mayor y, además, en los procesadores de 64 bits, la aritmética de enteros y las comparaciones deberían ser muy rápidas.
No tengo medidas para respaldar las afirmaciones anteriores. El beneficio neto de elegir un tipo de datos sobre otro depende mucho de los patrones de datos y tipos de consultas en su base de datos y aplicación. Para obtener la respuesta más precisa, debe probar ambas soluciones y medir la diferencia.
Re. su suposición de que la comparación de cadenas binarias es más rápida que la comparación de cadenas predeterminada que no distingue entre mayúsculas y minúsculas, probé la siguiente prueba:
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)
Por lo tanto, la comparación de cadenas binarias es un 17,5 % más rápida que la comparación de cadenas que no distingue entre mayúsculas y minúsculas. Pero observe que después de evaluar esta expresión 100 millones de veces, la diferencia total sigue siendo inferior a 1 segundo. Si bien podemos medir la diferencia relativa de velocidad, la diferencia absoluta de velocidad es realmente insignificante.
Así que reiteraré:
- Mida, no adivine ni suponga. Sus conjeturas educadas estarán equivocadas la mayor parte del tiempo. Mida antes y después de cada cambio que realice, para saber cuánto ayudó.
- Invierte tu tiempo y atención donde obtienes el mejor rendimiento por tu dinero.
- No te preocupes por las cosas pequeñas. Por supuesto, se suma una pequeña diferencia con suficientes iteraciones, pero dadas esas iteraciones, aún es preferible una mejora del rendimiento con un mayor beneficio absoluto.
