Sim. Muitas vezes, um resumo de hash é armazenado como a representação ASCII de dígitos hexadecimais, por exemplo, MD5 da palavra 'hash' é:
0800fc577294c34e0b28ad2839435945
Esta é uma string ASCII de 32 caracteres.
Mas o MD5 realmente produz um valor de hash binário de 128 bits. Isso deve requerem apenas 16 bytes para serem armazenados como valores binários em vez de dígitos hexadecimais. Assim, você pode ganhar alguma eficiência de espaço usando strings binárias.
CREATE TABLE test.foobar (
id BINARY(16) NOT NULL PRIMARY KEY
);
INSERT INTO test.foobar (id) VALUES (UNHEX(MD5('hash')));
Ré. seus comentários de que você está mais preocupado com o desempenho do que com a eficiência do espaço:
Não conheço nenhum motivo pelo qual o tipo de dados BINARY seja mais rápido que o CHAR.
Ter metade do tamanho pode ser uma vantagem para o desempenho se você usar buffers de cache com eficiência. Ou seja, uma determinada quantidade de memória cache pode armazenar duas vezes mais linhas de dados BINARY se a string tiver metade do tamanho do CHAR necessário para armazenar o mesmo valor em hexadecimal. Da mesma forma, a memória cache para o índice nessa coluna pode armazenar o dobro.
O resultado é um cache mais eficaz, porque uma consulta aleatória tem uma chance maior de atingir os dados ou índices armazenados em cache, em vez de exigir um acesso ao disco. A eficiência do cache é importante para a maioria dos aplicativos de banco de dados, porque geralmente o gargalo é a E/S de disco. Se você pode usar a memória cache para reduzir a frequência de E/S de disco, é um retorno muito maior do que a escolha entre um tipo de dados ou outro.
Quanto à diferença entre uma string de hash armazenada em BINARY versus uma BIGINT, eu escolheria BIGINT. A eficiência do cache será ainda maior, e também em processadores de 64 bits a aritmética inteira e as comparações devem ser muito rápidas.
Eu não tenho medidas para apoiar as reivindicações acima. O benefício líquido de escolher um tipo de dados em detrimento de outro depende muito dos padrões de dados e dos tipos de consultas em seu banco de dados e aplicativo. Para obter a resposta mais precisa, você deve tentar as duas soluções e medir a diferença.
Ré. sua suposição de que a comparação de strings binárias é mais rápida que a comparação de strings que não diferencia maiúsculas de minúsculas, tentei o seguinte teste:
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)
Portanto, a comparação de strings binárias é 17,5% mais rápida do que a comparação de strings que não diferencia maiúsculas de minúsculas. Mas observe que depois de avaliar essa expressão 100 milhões de vezes, a diferença total ainda é menor que 1 segundo. Embora possamos medir a diferença relativa de velocidade, a diferença absoluta de velocidade é realmente insignificante.
Então vou reiterar:
- Meça, não adivinhe ou suponha. Suas suposições educadas estarão erradas na maior parte do tempo. Meça antes e depois de cada alteração que você fizer, para saber o quanto isso ajudou.
- Invista seu tempo e atenção onde você obtém o melhor retorno possível.
- Não se preocupe com coisas pequenas. É claro que uma pequena diferença aumenta com iterações suficientes, mas, dadas essas iterações, uma melhoria de desempenho com maior benefício absoluto ainda é preferível.
