да. Често хеш дайджест се съхранява като ASCII представяне на шестнадесетични цифри, например MD5 на думата „хеш“ е:
0800fc577294c34e0b28ad2839435945
Това е 32-знаков ASCII низ.
Но MD5 наистина произвежда 128-битова двоична хеш стойност. Това трябва изискват само 16 байта да се съхраняват като двоични стойности вместо шестнадесетични цифри. Така че можете да постигнете известна ефективност на пространството, като използвате двоични низове.
CREATE TABLE test.foobar (
id BINARY(16) NOT NULL PRIMARY KEY
);
INSERT INTO test.foobar (id) VALUES (UNHEX(MD5('hash')));
Re. вашите коментари, че сте по-загрижени за производителността, отколкото за ефективността на пространството:
Не знам за причина типът данни BINARY да е по-бърз от CHAR.
Да бъдеш наполовина по-голям може да бъде предимство за производителността, ако използвате ефективно буферите на кеша. Тоест, дадено количество кеш памет може да съхранява два пъти повече редове на стойност BINARY данни, ако низът е половината от размера на CHAR, необходим за съхраняване на същата стойност в шестнадесетичен. По същия начин кеш паметта за индекса на тази колона може да съхранява два пъти повече.
Резултатът е по-ефективен кеш, тъй като произволна заявка има по-голям шанс да удари кешираните данни или индекс, вместо да изисква достъп до диск. Ефективността на кеша е важна за повечето приложения за бази данни, тъй като обикновено тесното място е дисков I/O. Ако можете да използвате кеш паметта, за да намалите честотата на дисковия вход/изход, това е много по-голям удар за парите, отколкото избора между един или друг тип данни.
Що се отнася до разликата между хеш низ, съхранен в BINARY спрямо BIGINT, бих избрал BIGINT. Ефективността на кеша ще бъде още по-голяма, а също и на 64-битови процесори целочислената аритметика и сравненията трябва да са много бързи.
Нямам измервания в подкрепа на твърденията по-горе. Нетната полза от избора на един тип данни пред друг зависи много от моделите на данни и видовете заявки във вашата база данни и приложение. За да получите най-точния отговор, трябва да опитате и двете решения и да измерите разликата.
Re. Вашето предположение, че сравнението на двоични низове е по-бързо от сравнението на низове, независимо от главни и малки букви по подразбиране, опитах следния тест:
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% по-бързо от сравнението на низове, независимо от главните букви. Но забележете, че след оценка на този израз 100 милиона пъти, общата разлика все още е по-малко от 1 секунда. Въпреки че можем да измерим относителната разлика в скоростта, абсолютната разлика в скоростта е наистина незначителна.
Така че ще повторя:
- Измервайте, не предполагайте и не предполагайте. Вашите образовани предположения ще бъдат погрешни през повечето време. Измервайте преди и след всяка промяна, която правите, за да знаете колко е помогнало.
- Инвестирайте времето и вниманието си там, където получавате най-добрия ефект за парите.
- Не се притеснявайте от дребните неща. Разбира се, малка разлика се допълва с достатъчно итерации, но като се имат предвид тези повторения, подобрението на производителността с по-голяма абсолютна полза все още е за предпочитане.
