![]() |
![]() |
Syntaxí řízená optimalizace
Někdy je zajímavé pozorovat, jak se dají jisté triky vznešeně pojmenovat. Přesně tak je tomu se syntaxí řízenou optimalizací. Předpokládá se zde, že uživatel zahrne informaci pro optimalizaci do textu dotazu samotného, tj. přinutí vlastně optimalizátor provést jistý prováděcí plán. V některých relačních SŘBD je např. značný rozdíl v provedení následujících dvou dotazů: SELECT * FROM FILM WHERE FILM.CENA > 8 AND FILM.ZEMĚ = 'Rumunsko' a SELECT * FROM FILM WHERE FILM.ZEMĚ = 'Rumunsko' AND FILM.CENA > 8 Optimalizátor předpokládá, že podmínka s nejmenší selektivitou (podíl počtu vybraných řádků ku všem řádkům) je umístěna jako první, tj. první dotaz zřejmě povede k velmi pomalému vyhodnocení, druhý dotaz bude naopak rychlejší, předpokládáme-li, že je jen malé množství rumunských filmů v databázi filmové distribuce a běžnou cenu filmu větší než 8 mil. (Kč). Nevýhody tohoto postupu jsou nesporné. Uživatelská aplikace se stává závislá na konstrukci vyhodnocovacího algoritmu. Uživatelé neříkají pouze "co chtějí", ale i "jak to získat", což odporuje základní myšlence použití SŘBD. Navíc, změní-li se např. velikosti relací, je nutné již "vyladěný" dotaz znovu ručně optimalizovat. Dalším problémem může být, že řada aplikací automaticky generuje SQL příkazy, přičemž nemusí být jasné, na jakém databázovém stroji budou tyto příkazy zpracovány a hlavně nad jakou databází budou prováděny. Nelze tedy předem ručně zařídit vhodnou syntaxi dotazu. Další případ, kdy uživatel může pozitivně ovlivnit vyhodnocení dokonce v případě, kdy existuje optimalizátor, je v dotazu SQL při použití OR za WHERE. Uvažujme dotaz "Vypiš z relace FILM n-tice týkající se filmů z Velké Britanie natočených po roce 1988 nebo n-tice týkající se filmů z Rumunska". SELECT * FROM FILM WHERE (ROK > '1988' AND ZEMĚ = 'Velká Britanie') OR ZEMĚ = 'Rumunsko' Optimalizátor bude mít tendenci zpracovat relaci FILM sekvenčně, dokonce i když existuje index pro atributy ZEMĚ i ROK. Jde o strategii, že od jisté složitosti logické podmínky již optimalizátor nehledá žádný “inteligentní plán”, ale přistupuje ke zpracování hrubou silou, tj. sekvenčně. Vhodnější je proto použít UNION a zapsat dotaz ekvivalentně jako SELECT * FROM FILM WHERE (ROK > '1988' AND ZEMĚ = 'Velká Britanie') UNION SELECT * FROM FILM WHERE ZEMĚ = 'Rumunsko' Optimalizátor zřejmě použije indexy pro každý poddotaz. Jiný trik lze použít v případě, že k více atributům v podmínce dotazu existuje index. Optimalizátory se často chovají tak, že použijí více indexů je tehdy, když podmínky obsahují pouze konjunkci rovností, např. ROK = '1988' AND ZEMĚ = 'Velká Britanie'. V ORACLE serveru verze 6 existovalo omezení na použití nejvíce 5 takových indexů pro jeden dotaz. Jsou-li ovšem některé podmínky jiného typu, vybere se index pouze jeden. Uvažujme dotaz SELECT * FROM FILM WHERE (ROK = 1988 AND ZEMĚ LIKE 'No%') Protože filmů ze zemí Norsko, Nový Zéland apod. je zřejmě méně než všech filmů z roku 1988, chtěli bychom přinutit optimalizátor, aby vybral index pro atribut ZEMĚ. Toho se docílí syntaktickou variantou dotazu SELECT * FROM FILM WHERE (ROK = 1988 + 0 AND ZEMĚ LIKE 'No%') Využije se totiž toho, že optimalizátor nepouživá index pro atribut porovnávaný s výrazem. Zkusme nyní dotaz používající SELECT bez klauzule WHERE, např. “Najdi země, jichž žádný film se zrovna nehraje”. SELECT ZEMĚ FROM FILM WHERE FILM.JMÉNO_FILMU NOT IN (SELECT JMÉNO_FILMU FROM PŘEDSTAVENÍ) I když existuje index na JMÉNO_FILMU v PŘEDSTAVENÍ, nevyužije se, protože JMÉNO_FILMU se v relaci PŘEDSTAVENÍ nevyskytuje za WHERE. Použití indexu lze vynutit příkazem SELECT ZEMĚ FROM FILM WHERE NOT EXISTS (SELECT PŘEDSTAVENÍ. JMÉNO_FILMU FROM PŘEDSTAVENÍ WHERE FILM.JMÉNO_FILMU = PŘEDSTAVENÍ .JMÉNO_FILM Takový dotaz je ovšem hnízděný a je nyní otázkou, jakou strategií se bude vyhodnocovat. Některé hnízděné dotazy lze převést na zápis pouze s jedním SELECT příkazem. Každý uhádne, že se syntaxí řízenou optimalizací můžeme dostat do pokusů ne nepodobných alchymii.Některé firmy proto přímo poskytují návod, jak psát SQL dotazy, jakou formu syntaxe zvolit, aby dotaz byl vyhodnocen co nejefektivněji. Existují ovšem také přístupy, kdy lze pro daný dotaz přímo navrhnout plán vyhodnocení. Při “životně důležitých” dotazech může takový přístup míst svůj dobrý smysl. <seznam dílů seriálu> <COMPUTERWORLD> |