Ja. Vaak wordt een hash-samenvatting opgeslagen als de ASCII-representatie van hexadecimale cijfers, bijvoorbeeld MD5 van het woord 'hash' is:
0800fc577294c34e0b28ad2839435945
Dit is een ASCII-tekenreeks van 32 tekens.
Maar MD5 produceert echt een 128-bits binaire hash-waarde. Dit moet vereisen dat slechts 16 bytes worden opgeslagen als binaire waarden in plaats van hexadecimale cijfers. U kunt dus wat ruimte besparen door binaire strings te gebruiken.
CREATE TABLE test.foobar (
id BINARY(16) NOT NULL PRIMARY KEY
);
INSERT INTO test.foobar (id) VALUES (UNHEX(MD5('hash')));
Met betrekking tot. uw opmerkingen dat u zich meer zorgen maakt over de prestaties dan over de ruimte-efficiëntie:
Ik ken geen enkele reden waarom het BINARY-gegevenstype sneller zou zijn dan CHAR.
Half zo groot zijn kan een voordeel zijn voor de prestaties als u cachebuffers effectief gebruikt. Dat wil zeggen, een gegeven hoeveelheid cachegeheugen kan twee keer zoveel rijen aan BINARY-gegevens opslaan als de tekenreeks half zo groot is als de CHAR die nodig is om dezelfde waarde in hex op te slaan. Evenzo kan het cachegeheugen voor de index op die kolom twee keer zoveel opslaan.
Het resultaat is een effectievere cache, omdat een willekeurige query een grotere kans heeft om de gegevens of index in de cache te raken, in plaats van dat er schijftoegang nodig is. Cache-efficiëntie is belangrijk voor de meeste databasetoepassingen, omdat het knelpunt meestal schijf-I/O is. Als u cachegeheugen kunt gebruiken om de frequentie van schijf-I/O te verminderen, is dat een veel grotere waar voor uw geld dan de keuze tussen het ene of het andere gegevenstype.
Wat betreft het verschil tussen een hash-string die is opgeslagen in BINARY versus een BIGINT, ik zou BIGINT kiezen. De cache-efficiëntie zal nog groter zijn, en ook op 64-bits processors zouden integer rekenen en vergelijkingen erg snel moeten zijn.
Ik heb geen metingen om de bovenstaande beweringen te ondersteunen. Het nettovoordeel van het kiezen van het ene gegevenstype boven het andere hangt sterk af van gegevenspatronen en typen query's in uw database en toepassing. Om het meest nauwkeurige antwoord te krijgen, moet u beide oplossingen proberen en het verschil meten.
Met betrekking tot. uw veronderstelling dat binaire tekenreeksvergelijking sneller is dan standaard hoofdletterongevoelige tekenreeksvergelijking, heb ik de volgende test geprobeerd:
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)
Dus binaire stringvergelijking is 17,5% sneller dan hoofdletterongevoelige stringvergelijking. Maar merk op dat na 100 miljoen keer evalueren van deze uitdrukking, het totale verschil nog steeds minder dan 1 seconde is. Hoewel we het relatieve snelheidsverschil kunnen meten, is het absolute verschil in snelheid echt onbeduidend.
Dus ik herhaal:
- Meet, niet raden of veronderstellen. Uw weloverwogen gissingen zullen vaak verkeerd zijn. Meet voor en na elke wijziging die u aanbrengt, zodat u weet hoeveel het heeft geholpen.
- Investeer uw tijd en aandacht waar u het meeste waar voor uw geld krijgt.
- Maak je geen zorgen over de kleine dingen. Natuurlijk telt een klein verschil op bij voldoende iteraties, maar gezien die iteraties heeft een prestatieverbetering met een groter absoluut voordeel nog steeds de voorkeur.