Optimalizace výkonu v MS SQL Management Studio

Optimalizaci databáze provádíme většinou přidáním databázového indexu na sloupec nebo skupinu sloupců, které často figurují v podmínkách dotazů. Optimalizace se často provádí až po vytvoření aplikace a to pouze u dotazů, které trvají dlouho nebo se spouští velmi často (vygenerování stránky trvá déle, než 500ms). Nemá smysl plýtvat časem vývojářů na optimalizaci dotazu, který se spouští jen zřídka. Z mých zkušeností lze ušetřit čas hlavně na straně serverového jazyka (např. PHP je velmi pomalé) než na straně databáze, které bývají většinou velmi rychlé.

U optimalizace databáze postupujeme následovně:

Obvykle se nejprve podíváme, zda je dotaz v pořádku a zda by nešel vyřešit lépe. Občas se díváme na problém ze špatného úhlu a zbytečně bychom optimalizovali špatný dotaz, když se může položit jinak.

Dále zkontrolujeme přítomnost databázových indexů, pokud znáte teorii okolo vyhledávacích algoritmů (stromů), určitě víte, že to má na výkon obrovský vliv.

Pokud máme s aplikací stále výkonnostní problémy, můžeme přistoupit k tzv. denormalizaci, kdy spojíme 2 nebo více tabulek do jedné, abychom se vyhnuli JOINování. Takováto operace má potom samozřejmě nepříznivý vliv na návrh aplikace. Bohužel často platí nepřímá úměrnost mezi hezky napsanou aplikací (míněno po stránce zdrojového kódu) a rychlou aplikací.

My si zde ukážeme nejčastější způsob optimalizace a to přidáním indexu na sloupec. Opět navážeme na náš vzdělávací projekt a vymyslíme si s ním výkonnostní problém.

Problém

Po několika měsících provozu se výrazně zvýšila zátěž serveru a nastala potřeba tuto situaci řešit. Nejčastějším dotazem je zobrazení obsahu článku podle sloupce PrettyURL. Tato hodnota se serveru odešle jako parametr v GET a server podle něj nalezne a vrátí požadovaný článek. K tomuto sloupci není přiřazen žádný index, což se podepisuje na výkonu aplikace.

Přidání databázového indexu

Ačkoli se na testovacích datech patrně neprojeví žádná změna, rád bych nastínil, jak by optimalizace probíhala na skutečných datech. V nástroji SQL Server Management Studio spustíme dotaz na výběr článku dle PrettyURL a necháme si vygenerovat Execution plan pomocí tlačítka :

SELECT
    c.Perex,
    c.PrettyURL,
    c.Keywords,
    c.Titulek,
    c.Obsah,
    c.Publikovano,
    u.Nick
FROM Clanek c, Uzivatel u
WHERE ((c.PrettyURL = 'co-je-to-algoritmus')
    AND (c.AutorID = u.UzivatelID));

Výsledek bude vypadat např. takto:

A jednotlivé parametry:

Následně vytvoříme index na sloupci PrettyURL:

CREATE INDEX idx_clanek_prettyurl ON Clanek (PrettyURL);

Opětovné vyvolání Execution plan by na ostré databázi, která by jistě měla několik desítek MB, jistě přineslo výrazné změny. Na testovacích datech se změna vůbec neprojeví, nicméně jsme si to alespoň vyzkoušeli