Většina rad je způsob, jak sdělit náš záměr optimalizátoru. Například leading nápověda, kterou zmiňujete, znamená připojit tabulky v tomto pořadí . Proč je to nutné? Často je to proto, že optimální pořadí spojení není zřejmé, protože dotaz je špatně napsaný nebo statistiky databáze jsou nepřesné.
Takže jedno použití nápověd, jako je leading je zjistit nejlepší způsob provedení a pak zjistit, proč databáze nezvolí tento plán bez nápovědy. Vyřeší problém shromažďování nových statistik? Vyřeší problém přepsání klauzule FROM? Pokud ano, můžeme odstranit rady a nasadit nahé SQL.
Někdy nastanou situace, kdy nedokážeme vyřešit tento hlavolam a musíme ponechat rady ve výrobě. To by však měla být vzácná výjimka. Oracle má mnoho velmi chytrých lidí, kteří pracují na Cost-Based Optimizer po mnoho let, takže jeho rozhodnutí jsou obvykle lepší než naše.
Existují ale i další náznaky, kvůli kterým bychom v Production ani nemrkli. append je často rozhodující pro ladění bulk insertů. driving_site může být zásadní při ladění distribuovaných dotazů.
Naopak jiné narážky jsou téměř vždy zneužívány. Ano parallel , mluvím o tobě. Slepé uvedení /*+ parallel (t23, 16) */ pravděpodobně nezrychlí váš dotaz šestnáctkrát a nezřídka bude mít za následek pomalejší načítání než jednovláknové provádění.
Takže zkrátka neexistuje žádná univerzálně použitelná rada, kdy bychom měli používat nápovědu. Klíčové věci jsou:
- porozumět tomu, jak databáze funguje, a zejména jak funguje optimalizátor založený na nákladech;
- pochopit, co jednotlivé tipy dělají;
- otestujte naznačené dotazy ve vhodném ladícím prostředí s daty ekvivalentními k produkci.
Je zřejmé, že nejlepším místem pro začátek je dokumentace Oracle . Pokud však máte chuť utratit nějaké peníze, kniha Jonathana Lewise o nákladovém optimalizátoru je tou nejlepší investicí, kterou můžete udělat.