Vlákno názorů k článku
Co nefunguje v MySQL a jak to obejít

s dotazem SELECT * FROM tabulka WHERE zmeneno + INTERVAL 1 DAY >= NOW(); by mel problem i PostgreSQL – co vim tak ktera-koliv databaze. Porusuje jedno zakladni pravidlo – setkal jsem se s terminem „cisty predikat“. Za vsech okolnosti by predikaty mely byt zadavany ve forme < sloupec OPERATOR vyraz > (pokud chceme, aby se chytily indexy).

V PostgreSQL lze indexovat pouze tzv. immutable funkce – mezi nez NOW nepatri.

to je ale hloupost databáze: má si to sama zoptimalizovat na:
WHERE zmeneno >= NOW() – INTERVAL 1 DAY

Tohle nedělá co vím žádná databáze. Optimalizace dotazu je na programátorovi, DB optimalizuje až samotný prováděcí plán.

Nejsem databazista, takze mozna trochu hloupy dotaz: Jestli ten „vyraz“ provadi to same a v jednom pripade to dokaze udelat rychleji a efektivneji, proc to databazova masina nezoptimalizuje? U jazyku ala C/C++ je naprosto normalni, ze prekladac zvoli optimalni reseni (bud preferovana rychlost / veliksot kodu atp) za predpokladu, ze to dava stejny vysledek.

Optimalizace v db se soutřeďují na dohledání optimálního prováděcího plánu. Optimalizace samotných výrazů, alespoň co je mi známo, neexistuje. Důvod je prostý – rychlost zpracování dotazů. Pokud se nepoužíjí prepared staments, tak více-méně každý dotaz prochází stejnými etapami: parsování, transformace, generování a výběr plánu, provedení plánu. Důraz je na výběr optimálního prováděcího plánu – to má největší vliv na rychlost provedení dotazu. Optimalizace plánu je relativně náročná úloha – takže na vlastní parsování a transformace není čas. V případě SQL platí přelož, optimalizuj a zahoď (ve velké většině případů). Prepared statements případně fixované plány bohužel nejsou 100% řešení.

C/C++ má odlišný přístup – přelož, optimalizuj, ulož a volej opakovaně. Na samotnou optimalizaci je mnohem více času – a nikomu to nevadí – např. srovnejte čas překladu C a Pascalu.

Asi by bylo možné napsat kód, který by dokázal izolovat predikát – takový sw existuje – je ale dost možné, že tato samotná úloha by trvala déle než provedení zbytku dotazu. Takže zápis výrazů se nechává na inteligenci programátora – předpokládá se, že tak jednoduché pravidlo dokáže respektovat i cvičená opice – tudíž i sebeprostší kó­dér.

Ono je optimalizace a je optimalizace. V tomto případě se snažíme řešit úlohu přeskládání výrazu „f(x) ? g(x)“ na „x ? c“ (kde ? značí porovnání). Z analytického hlediska velmi náročná úloha a rozhodně ne něco, co by se dalo provádět při každém dotazu. Některé DB se snaží tu úlohu nějak řešit a optimalizovat alespoň to „do očí bijící“. Kupříkladu Oracle umí převádět „x ± a ? b“ na „x ? b -+ a“. To řeší nejčastější problémy s podmínkami na intervaly. Ale už jen takové „2 * x = 2“ na „x = 1“ převést neumí. Asi i to by se dalo, ale zpomalení překladu by za to nestálo.

Jednoduše řečeno, v případě DB se nejedná o optimalizaci vyhodnocení výrazu, ale o jeho převedení na formu, kdy na jedná straně bude sloupec z databáze a na té druhé konstanta.

Kupříkladu dotaz na faktury, kde je částka DPH větší než 1000 Kč:
faktury.castka_bez_DPH * 0.09 >= 1000

To znamená, že se pro každý řádek provede vynásobení hrubé částky sazbou daně a to se porovná na 1000. Optimální by ale bylo:
faktury.castka_bez_DPH >= 1000 / 0.09

Protože vpravo je konstanta a vy pak jen porovnáváte hodnotu ve sloupci s touto konstantou. Pokud je sloupec zaindexovaný, nemusíte procházet všechny řádky v tabulce.

Poznámka: uvedený příklad je samozřejmě špatně. Díky zaokrouhlovací chybě nejsou oba výrazy ekvivalentní. Pokud čásku bez DPH uvedu na stejný počet desetinných míst jako podíl 1000/0.09, nebude to fungovat. Při dvou desetinných místech viz částka 11111.11 Kč. Další důvod, proč neoptimalizovat automaticky.

Oracle ve verzi 8 to dělal, jak novější netuším. Ale jen pokud to považoval za vhodné. Nikdy jsme úspěšně nevysledovali, kdy to uzná za vhodné a tudíž i pro Oracle jsme se snažili mít na jedné straně sloupce a na druhé to ostatní.

Ono by to asi šlo, jenomže pak by se časy provedení dotazů nepohybovalo v milisec, ale spíš v desítkách až stovkách sec. Navíc tuto transformaci by měl zvládnout absolovent základní školy, kdežto výběr optimálního plánu už asi ne, takže důraz je na generování prováděcích plánů.

Ty desítky až stovky sekund jsou trochu mimo možnou realitu :)

sorry – myslel jsem milisec