Vlákno názorů k článku Co nefunguje v MySQL a jak to obejít od Pavel Stěhule - s dotazem SELECT * FROM tabulka WHERE zmeneno +...
-
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.
-
Tango (neregistrovaný)
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.
-
Karel (neregistrovaný)
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 >= 1000To 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.09Protož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.
ČLÁNKY DO MAILU