sql >> Databáze >  >> RDS >> Mysql

Výkon MySQL BIGINT(20) vs Varchar(31).

To by se opravdu muselo změřit, můžeme udělat nějaké "hádání" na základě toho, co víme a co předpokládáme, ale to jsou jen domněnky.

Neuvádíte, zda je tato tabulka InnoDB nebo MyISAM s dynamickými řádky nebo MyISAM s řádky s pevnou délkou. To bude nějaký rozdíl.

Ale pro hodnoty, jako je ta, kterou jste zveřejnili, '961637593864109_412954765521130' (31 znaků), za předpokladu, že používáte jednobajtovou znakovou sadu (např. latin1) nebo znakovou sadu, která tyto konkrétní znaky zakóduje do jednoho bajtu (např. utf8)...

Pro dynamický formát InnoDB a MyISAM je to 31+1-8=24 bajtů navíc pro daný řádek. (BIGINT se vejde do 8 bajtů, hodnota VARCHAR(31) 31 znaků použije 32 bajtů.)

U tabulky MyISAM s řádky s pevnou délkou by to byl rozdíl 23 bajtů na řádek. (Mezera je vyhrazena pro všech 31 znaků a délka nemusí být uložena.)

Tato hodnota primárního klíče se bude také opakovat v každém indexu, takže u každého indexu je také větší prostor.

Za předpokladu, že vaše řádky tabulky mají 120 bajtů pomocí BIGINT a řádky mají 144 bajtů s VARCHAR, je to 20 % zvýšit. Čím větší řádky, tím menší procentuální nárůst a naopak.

Pro 1 000 000 řádků (chci říct „jeden meelyun řádky“ stejným způsobem, jako když Dr. Evil přiloží malíček ke koutku úst a řekne „jeden milion dolarů“), těch dalších 24 bajtů na řádek čítá celkem asi 24 MB.

Jenže ono to vlastně není tak jednoduché. Pokud jde o prostor InnoDB, jde o to, jak mohou řádky "zapadnout" do bloku. Čím větší je průměrná velikost řádku, tím větší bude množství volného místa v bloku.

Pokud s řádky neděláte nic jiného než je ukládáte na disk, pak je to ve skutečnosti jen zvětšení místa na disku a čas a prostor navíc pro zálohy.

Pokud se stejný počet řádků "144 bajtů" vejde do bloku jako řádků "120 bajtů", neuvidíte žádný rozdíl v prostoru. Pokud se ale do bloku vejde méně řádků, je to více bloků, více místa ve fondu vyrovnávací paměti InnoDB, více vstupů a výstupů atd.

U dotazů na jeden řádek, buď podle hodnoty primárního klíče, nebo pomocí nějakého jiného jedinečného vyhledávání indexu, bude rozdíl zanedbatelný.

Pokud máte co do činění s většími sadami výsledků, pak je to paměť navíc pro přípravu sady výsledků a další bajty pro přenos do klienta atd.

Pokud je klíč VARCHAR navržen tak, že „skupiny“ řádků, ke kterým se přistupuje společně, mají stejnou úvodní část hodnoty klíče, pak s InnoDB může skutečně dojít k určitému zlepšení výkonu. Je to proto, že primárním klíčem je klíč clusteru... mnohem větší šance, že řádky potřebné ke splnění dotazu budou ve stejném bloku, než aby byly rozmístěny po hromadě bloků.

Opakem je, že pokud se provádějí vkládání a mazání, v některých blocích bude více volného místa. (Po odstranění zůstane v bloku místo pro smazané řádky; abyste jej mohli znovu použít, musíte vložit řádek, který měl stejnou hodnotu klíče (nebo alespoň hodnotu klíče dostatečně blízko, aby přistála ve stejném bloku .) A s náhodnými vložkami získáme rozdělení bloků.




  1. Migrace z Postgres na SQL Server 2008

  2. vyčištění db redundantních dat

  3. Volání funkce PostgreSQL

  4. Jak opravit „Procedura očekává parametr ‚@statement‘ typu ‚ntext/nchar/nvarchar‘.“ Chyba na serveru SQL Server