Zvýšení výkonu MySQL databází díl 2

Přečtěte si také první díl, abyste byli v obraze.

Analýza dotazu

Pomocí klíčového slova EXPLAIN na začátku dotazu si můžete zobrazit výpis, jak se dotaz vykonával. Na obrázku pod dotazem jsou zobrazeny různé případy s použitím indexu i bez.

EXPLAIN SELECT K.zacatek, K.konec, K.jmeno_1, Z.jmeno, Z.prijmeni
FROM kurzy K
JOIN zaci Z ON K.id = Z.kurz
WHERE Z.pujcovne_vyska IS NOT NULL AND Z.platba = 2 AND Z.mesto LIKE 'Ostrava%'

Na obrázku můžete vidět, že pro nalezení kurzu se projde 1 řádek díky indexu PRIMARY, který je unikátní. Pro nalezení žáků ale procházíme různé počty řádků. Zajímavé je, že při indexu na mesto i platba server vybere vyhledání podle platby, přesto že prochází více řádků. Tento způsob je pro něj asi rychlejší a optimalizátor dotazu vybral právě tuto možnost.

Nejméně řádků se prochází, pokud máme složený index. Mějte ale na paměti, že indexy zpomalují vkládání, mazání a úpravu a také zabírají více místa viz díl 1.

Výhoda UNIQUE indexu

Jak jsme si říkali v prvním díle. Pokud víme, že dotaz vrátí 1 řádek, je dobré použít LIMIT 1 nebo vložit UNIQUE index. Dobrá ukázka je na následujícím dotazu, kde login bude unikátní.

SELECT *
FROM users
WHERE login = 'pavelkutac'

V případě bez UNIQUE indexu server prošel veškeré řádky v tabulce. Pokud ale přidáme UNIQUE index, projde jen jediný řádek a to ten náš.

Analýza obsahu

Způsob analyzování obsahu vám napoví, jak můžete upravit jednotlivé sloupce pro rychlejší a úspornější ukládání. Jsou to ale pouze návrhy a dobře se rozmyslete, jestli jsou opravdu nutné! Z principu je jasné, že tabulka musí být plná daty, jinak analýza neproběhne.

V mém případě jsem spustil analýzu na tabulce wp_posts na webu susostrava.eu, která má téměř 13 000 řádků. Využijeme pro to proceduru ANALYSE.

SELECT * FROM wp_posts PROCEDURE ANALYSE();

Výsledek obsahuje poměrně velké množství různých informací. V posledním sloupci jsou právě informace týkající se možného zlepšení sloupce.

Jak vidíte, některé sloupce bychom mohli zmenšit nebo převést na ENUM. Je ale opravdu na zvážení, které úpravy by se hodily. Databáze stále poroste a převést post_author na ENUM by dobré nebylo. post_status který momentálně ve WP nelze rozumně využít by na ENUM převést šel v případě vypsání všech možných stavů.

---

Čerpal jsem z látky probrané na VŠ tak také v článku Top 20+ MySQL Best Practices.