Je snadné začít si pohrávat s ozubenými koly optimalizace dotazů SQL. Spustíte SQL Server Management Studio (SSMS), budete sledovat dobu čekání, zkontrolovat plán spouštění, shromáždit informace o objektech a začít optimalizovat SQL, dokud nezačnete provozovat jemně vyladěný počítač.
Pokud jste v tom dost dobří, dosáhnete rychlého vítězství a vrátíte se do svého pravidelně naplánovaného chaosu. Ale pokud upravíte špatnou věc nebo upravíte správnou věc špatným směrem, tak tady je vaše středa.
Optimalizace dotazů SQL? Proč si myslíte, že to potřebujete?
Většinu času je to prudký nárůst problémů nebo stížností uživatelů. "Proč je systém tak pomalý?" vaši uživatelé si stěžují. "Trvá nám věčnost, než tento týden spustíme naše obvyklé přehledy."
To je samozřejmě dost vágní popis. Bylo by hezké, kdyby vám řekli:„Věci jsou pomalé, protože na řádku 62 CurrentOrderQuery5.sql máte implicitní konverzi. Sloupec je varchar a vy předáváte celé číslo." Není však pravděpodobné, že vaši uživatelé uvidí takovou úroveň podrobností.
Přinejmenším problémové lístky a telefonní hovory tvoří aktivní metriku:snadno zjistitelné, snadno měřitelné. Když se začnou používat, můžete si být přiměřeně jisti, že je čas na vyladění SQL.
Existují však i jiné, pasivní metriky, díky nimž je potřeba méně jasná. Věci jako propad prodeje, který může být způsoben mnoha faktory. Je to proto, že bolestně pomalé dotazy ve vašem internetovém obchodě nutí vaše zákazníky opouštět nákupní vozíky? Je to proto, že ekonomika je ve špatném stavu?
Nebo to mohou být věci jako pomalý výkon SQL Serveru. Je to proto, že špatně napsaný dotaz posílá logická čtení přes střechu? Je to proto, že server má málo fyzických zdrojů, jako je paměť a úložiště?
V obou scénářích může optimalizace dotazů SQL pomoci s první možností, ale nikoli s druhou.
Proč použít správné řešení na nesprávný problém?
Než se vydáte cestou optimalizace, ujistěte se, že ladění je správným řešením správného problému.
Ladění SQL je technický proces, ale každý technický krok má kořeny v dobrém obchodním smyslu. Mohli byste strávit dny pokusy zkrátit dobu provádění o několik milisekund nebo snížit počet logických čtení o pět procent, ale stojí toto snížení za váš čas? Je pravda, že je důležité splnit požadavky uživatelů, ale veškeré úsilí nakonec dosáhne bodu, kdy se výnosy snižují.
Zvažte tyto problémy s výkonem dotazů SQL a obchodní kontext kolem nich:
- Přijatelný výkon — Spuštění dotazu trvá 10 minut a uživatel chce, aby byl spuštěn za jednu minutu; to vypadá jako rozumný nepoměr a dosažitelný cíl optimalizace. Pokud však dotaz trvá přes noc a uživatel si myslí, že by se měl spustit do jedné minuty, může to být více než jen problém s laděním. Za prvé, možná budete muset poučit uživatele o množství práce, kterou dotaz skutečně vykonává. Pro jiného to může být problém ve způsobu, jakým byla navržena databáze nebo jak byla napsána klientská aplikace.
- Nástroje — Předpokládejme, že jste odpovědní za správu finanční databáze ve výrobní společnosti. Na konci každého měsíce si uživatelé stěžují na špatný výkon. Vysledujete problém v sérii zpráv na konci měsíce, které spouští Účetnictví, z nichž každá trvá hodiny a jdou přímo do kartotéky, aniž by je kdokoli zkoumal. Místo ladění vysvětlíte problém obchodním manažerům a získáte povolení ke smazání sestav.
- Posun času — Nebo předpokládejme, že tytéž zprávy jsou důležité pro řízení, ale nejsou naléhavé pro podnik. Pokud se spouštějí jednou týdně nebo měsíčně, lze je naplánovat na hodiny mimo špičku pomocí předběžného ukládání datové sady do mezipaměti a odeslání výsledků do souboru. To odstraňuje překážku pro ostatní firemní uživatele a zbavuje uživatele Účetnictví čekání na zprávy.
Když při rozhodování o optimalizaci zohledníte obchodní kontext, můžete si stanovit priority a získat čas.
Když optimalizujete dotazy SQL, vyzkoušejte vytváření diagramů SQL
SSMS a nástroje zabudované do SQL Serveru nabízejí většinu toho, co potřebujete pro efektivní optimalizaci dotazů SQL. Zkombinujte nástroje s metodickým přístupem kolem následujících kroků, jak je popsáno v elektronické knize „Základní průvodce optimalizací dotazů SQL“:
- Monitorovat dobu čekání
- Zkontrolujte plán provádění
- Shromáždit informace o objektu
- Najděte jízdní stůl
- Identifikujte inhibitory výkonu
V kroku 4 je vaším cílem řídit dotaz pomocí tabulky, která vrací nejméně dat. Když studujete spojení a predikáty a filtrujete dříve v dotazu než později, snížíte počet logických čtení. To je velký krok v optimalizaci dotazů SQL.
Tvorba diagramů SQL je grafická technika pro mapování množství dat v tabulkách a zjištění, který filtr vrátí nejméně záznamů. Nejprve určíte, které tabulky obsahují podrobné informace a které tabulky jsou hlavní nebo vyhledávací. Zvažte jednoduchý příklad tohoto dotazu proti univerzitní registrační databázi:
Tabulka podrobností je registrace. Má dvě vyhledávací tabulky, student a třída. Chcete-li vytvořit diagram těchto tabulek, nakreslete převrácený strom spojující tabulku podrobností (nahoře) pomocí šipek (nebo odkazů) s vyhledávacími tabulkami, jako je tento:
Nyní vypočítejte relativní počet záznamů požadovaných pro kritéria spojení (tj. průměrný poměr řádků souvisejících mezi tabulkou podrobností a vyhledávacími tabulkami). Napište čísla na každý konec šipky. V tomto příkladu je pro každého studenta v registrační tabulce asi 5 záznamů a pro každou třídu je asi 30 záznamů v registraci. To znamená, že by nikdy nemělo být nutné PŘIPOJIT více než 150 (5×30) záznamů, abyste získali výsledek pro každého jednotlivého studenta nebo jednu třídu.
Toto cvičení je užitečné, pokud vaše sloupce spojení nejsou indexovány nebo pokud si nejste jisti, že indexovány jsou.
Dále se podívejte na predikáty filtrování a zjistěte, se kterou tabulkou se má dotaz řídit. Tento dotaz měl dva filtry:jeden na registraci zrušena =‚N‘ a druhý na datum_registrace mezi dvěma daty. Chcete-li zjistit, jak selektivní je filtr, spusťte tento dotaz při registraci:
vyberte počet(1) z registrace, kde je zrušeno =‚N‘
AND r.signup_date BETWEEN :beg_date AND :beg_date +1
Vrací 4 344 záznamů z celkových 79 800 záznamů v registraci. To znamená, že s tímto filtrem bude přečteno 5,43 procent záznamů.
Druhý filtr je na třídě:
vyberte počet(1) ze třídy, kde název =‚ENGLISH 101‘
Vrátí dva záznamy z 1 000 neboli 0,2 procenta, což představuje mnohem selektivnější filtr. Třída je tedy řídící tabulkou a ta, na kterou se nejprve zaměříte na ladění SQL.
Hlas uživatele
Pokud jste si jisti, že potřebujete vyladění SQL, „Základní průvodce optimalizací dotazů SQL“ nabízí další informace. Provede vás pěti tipy pro ladění výkonu pomocí dotazů zkopírovat a vložit a případových studií, včetně výše popsaného.
Pravděpodobně zjistíte, že nejdůležitějším nástrojem pro optimalizaci dotazů SQL je hlas uživatele. Proč? Protože tento hlas vám dá vědět, kdy začít s optimalizací, a řekne vám, kdy jste optimalizovali dostatečně. Může zajistit, že si začnete hrát s převody, když to potřebujete, a zastavíte se, když jste stále vepředu.