Při psaní dotazů nebo kódu databáze SQL Server (postupy a zobrazení) se vždy doporučuje vzít na vědomí plán provádění. Důvodů je několik. Za prvé – optimalizátor možná vybírá plán, který neočekáváte. Například indexové skenování velké tabulky před spárováním s menší tabulkou. Za druhé – je třeba vzít v úvahu, jak bude tento dotaz fungovat v následujících měsících nebo letech, pokud dotazy běží v novém systému s malými tabulkami, které se budou rozrůstat. A nakonec, ale to nejdůležitější, jak rychlý je tento dotaz a kolik zdrojů využívá. Poslední bod se nemusí zdát tak důležitý, možná si myslíte, že pokud to trvá méně než 3 sekundy, je to dost dobré, ale pokud by to šlo spustit za <1 sekundu, nebylo by to lepší? Pokud jsou vaše databáze hostované v cloudu, může vám omezení zdrojů také ušetřit peníze.
Mnoho případů optimalizace SQL obvykle pochází z problému, který zjistí koncový uživatel nebo váš monitorovací software. „Proč trvá generování tohoto přehledu 30 minut?“, „Co způsobuje ten prudký nárůst čekání na vstup/výstup“ nebo „Proč tyto úlohy trvají dvakrát déle než loni?“
Ve všech těchto scénářích stále záleží na určitých znalostech o plánech provádění a nejlepším způsobu, jak opravit SQL, aby se situace zlepšila, což může být velmi časově náročné a ne vždy úspěšné.
Vezměme si příklad. Takže píšete nový dotaz, provádíte ho a pak si říkáte, bože, to trvá příliš dlouho.
17 sekund pro 730 řádků, co mám dělat?
Nejprve si projdeme plán provádění:
To není vždy přímočaré, pokud musíte přibližovat a oddalovat, aby to dávalo smysl. Takže první radou je získat dobrý prohlížeč plánů, jako je tento s balíčkem Spotlight Tuning Pack.
Prohlížeč plánů zvýrazní klíčové části informací, které potřebujeme, a kde jsou hlavní operace, stejně jako zvýrazní všechna varování.
Zde je příklad:
S tímto kódem je tedy problém, ale co s tím můžeme dělat?
No, vlastně docela hodně. Mohli bychom použít nápovědu k dotazu, podívat se na přidání některých indexů (nezapomeňte, že to může ovlivnit jiné dotazy a DML), přidat kousky kódu, které nemění sadu výsledků, ale ovlivňují optimalizátor, aby vygeneroval jiný plán, a malé triky zastavte optimalizátor s ohledem na konkrétní index, který používá, a možná vygenerujte nový plán. Ale to vše je pokus a omyl a ruční provádění je velmi časově náročné.
Přidáním aplikace Spotlight Extensions do SSMS a přihlášením k odběru Spotlight Tuning Pack můžeme nechat funkci optimalizace v Tuning Pack, aby veškerou tvrdou práci dělala za nás.
Možná jste si na prvním snímku obrazovky všimli, že když je tato funkce povolena, automaticky detekuje, že je možná optimalizace:
Klikněte na Zobrazit analýzu
Poté můžete kliknout na tlačítko Optimalizovat a optimalizační modul analyzuje kód a začne aplikovat pravidla přepisu, která změní syntaxi SQL poskytující alternativy, které poskytují stejnou sadu výsledků, a poté je otestovat, abychom mohli zjistit, zda existuje alternativní provedení. plány jsou rychlejší a proč. Pravidla se používají v kombinacích, takže možných alternativ může být více než 100. Nástroj vám však zobrazí pouze alternativy, které jsou rychlejší než originál.
Tento proces běží na pozadí a ušetří vám nesmírné množství času, pokud se o to pokusíte ručně.
A když se zobrazí výsledky, můžete porovnávat alternativy, vidět rozdíly v kódech, porovnávat plány a kontrolovat statistiky.
Takže zpět k SSMS s mou novou verzí dotazu a otestujte ji.
Úspěch.
Pokud je to ve vývojovém prostředí, možná budete chtít zvážit vyprázdnění mezipaměti pomocí DBCC DROPCLEANBUFFERS, abyste otestovali své dotazy pomocí mezipaměti studené vyrovnávací paměti bez vypínání a restartování serveru.
Zvažte také přidání SET STATISTICS IO ON k dotazu, abyste získali další informace o tom, proč se syntaxe dotazu změnila:
Originál:
Přepište:
A toho lze také dosáhnout v balíčku Tuning Pack pomocí funkce porovnání statistik:
Takže s úspěšnou změnou a šťastným koncovým uživatelem přejděte k dalšímu dotazu. Neustálým zlepšováním výkonu jednotlivých dotazů zlepšujeme výkon instance.