MySQL binární proti nebinárnímu pro hash ID

Ano. Hash digest je často uložen jako ASCII reprezentace hexadecimálních číslic, například MD5 slova 'hash' je:

0800fc577294c34e0b28ad2839435945

Toto je řetězec ASCII o 32 znacích.

Ale MD5 skutečně produkuje 128bitovou binární hash hodnotu. Toto by mělo vyžadují pouze 16 bajtů k uložení jako binární hodnoty namísto hexadecimálních číslic. Použitím binárních řetězců tedy můžete získat určitou prostorovou efektivitu.

CREATE TABLE test.foobar (
  id BINARY(16) NOT NULL PRIMARY KEY
);

INSERT INTO test.foobar (id) VALUES (UNHEX(MD5('hash')));

Re. vaše komentáře, že se více zajímáte o výkon než o prostorovou efektivitu:

Nevím o žádném důvodu, proč by datový typ BINARY byl rychlejší než CHAR.

Poloviční velikost může být výhodou pro výkon, pokud mezipaměti používáte efektivně. To znamená, že dané množství mezipaměti může uložit dvojnásobný počet řádků v hodnotě BINARY dat, pokud má řetězec poloviční velikost než CHAR potřebné k uložení stejné hodnoty v šestnáctkové soustavě. Podobně může mezipaměť pro index v tomto sloupci uložit dvakrát tolik.

Výsledkem je efektivnější mezipaměť, protože náhodný dotaz má větší šanci zasáhnout data nebo index uložený v mezipaměti, místo aby vyžadoval přístup na disk. Efektivita mezipaměti je důležitá pro většinu databázových aplikací, protože úzkým hrdlem je obvykle diskový I/O. Pokud můžete použít mezipaměť ke snížení frekvence diskových I/O, je to mnohem větší rána než volba mezi jedním nebo druhým typem dat.

Pokud jde o rozdíl mezi hash řetězcem uloženým v BINARY a BIGINT, zvolil bych BIGINT. Efektivita mezipaměti bude ještě vyšší a také na 64bitových procesorech by měla být celočíselná aritmetika a porovnávání velmi rychlé.

Nemám míry na podporu výše uvedených tvrzení. Čistá výhoda výběru jednoho datového typu před jiným závisí hodně na vzorcích dat a typech dotazů ve vaší databázi a aplikaci. Chcete-li získat co nejpřesnější odpověď, musíte vyzkoušet obě řešení a změřit rozdíl.

Re. váš předpoklad, že porovnání binárních řetězců je rychlejší než výchozí porovnání řetězců bez ohledu na velikost písmen, jsem zkusil následující test:

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)

Porovnání binárních řetězců je tedy o 17,5 % rychlejší než porovnání řetězců bez rozlišení velkých a malých písmen. Všimněte si ale, že po vyhodnocení tohoto výrazu 100 milionkrát je celkový rozdíl stále menší než 1 sekunda. I když můžeme měřit relativní rozdíl v rychlosti, absolutní rozdíl v rychlosti je opravdu nevýznamný.

Takže zopakuji:

• Měřte, nehádejte ani nepředpokládejte. Vaše kvalifikované odhady budou často chybné. Měřte před a po každé změně, kterou provedete, abyste věděli, jak moc to pomohlo.
• Investujte svůj čas a pozornost tam, kde získáte největší ránu za peníze.
• Nepropoťte malé věci. Malý rozdíl se samozřejmě sčítá s dostatkem iterací, ale vzhledem k těmto iteracím je stále lepší zlepšení výkonu s větším absolutním přínosem.