Obvyklé problémy s SQL
Ne každý programátor má dostatečné zkušenosti s formulací relačních dotazů, ne každý výkonnostní problém je zřejmý už při psaní SQL dotazu, ne každý SQL dotaz je vyhodnocen tak jak bychom očekávali, a ne každý problém se projeví při zběžném otestování. Jednou z mých povinností u předchozího zaměstmavatele byl také dohled nad výkonem aplikací nad PostgreSQL databází a identifikace problematických SQL dotazů, setkával jsem se s velkým množstvím "rozbitých" SQL dotazů jejichž osobní "hitparádu" prezentuji v tomto seriálu několika volně navazujících článků.
Drtivá většina tohoto článku (resp. principů v něm uvedených) je samozřejmě aplikovatelná na relační databáze jako takové, ne pouze na PostgreSQL - základní principy totiž platí pro všechny relační databáze bez výjimky (ačkoliv se vás marketingová oddělení jednotlivých dodavatelů nepochybně budou snažit přesvědčit že zrovna jejich vývojáři dokázali obejít základní fyzikální zákony).
Nicméně ačkoliv principy platí univerzálně, jednotlivé databáze se mohou lišit v detailech (například podporovaných typech indexů, chování NULL hodnot v indexech, apod.), a zejména v poskytovaných nástrojích - při ladění dotazů hraje klíčovou roli zejména tzv. execution plan, tj. popis jak bude databáze postupovat při jeho vyhodnocování (jaké tabulky bude joinovat, jakým způsobem a v jakém pořadí, jaké podmínky bude vyhodnocovat pomocí indexů apod.) a způsob jeho získání se v jednotlivých databázích liší. PostgreSQL poskytuje příkaz EXPLAIN [ANALYZE], Oracle plní výsledky do tabulek (odkud je následně mohou číst další nástroje - sqlplus, TOAD, SQL Developer, ...) apod.
V tomto článku je pro demonstraci využíván PostgreSQL a je tedy využíván EXPLAIN [ANALYZE]. Pokud používáte jinou databázi, zjistěte si jak lze získat a zobrazit execution plan.
Tento článek rozhodně není vyčerpávajícím výčtem všech možných problémů kterých se lze při psaní SQL dotazů dopustit - jedná se pouze o příklady některých typických problémů, rozdělených do několika skupin dle příčiny.
