Pomalý SQL dotaz Microsoft SQL server

Na vině je optimalizace, kterou provádi SQL server a vypočtené statistiky pro tabulku. Mohlo se změnit statistické rozložení dat.Je jedno, kolik záznamů ten dotaz vrací, ale důležitý je návrh tabulky - hlavně indexů a zda používáš podmínky v dotazu, které ten index využijí.Mohl bys sem dát dotaz a informaci o indexech v tabulce (oznac, ktery je clusterovany)? Pro MS SQL server je 100 000 záznamů nic. S desítkami milonů záznamů v tabulce se optimalizované dotazy provedou do 1s.

Co můžeš udělat dnes, odlož na včerejšek.

Tak problém vyřešen - když jsem začal popisovat strukturu tabulek a indexů pro odpověď sem, tak jsem si všimnul jednoho propojení přes tři sloupce, kterému v jedné tabulce chyběl index, takže když jsem ho přidal, tak se to rázem zrychlilo.Jen mi přijde zajímavé, že když jsem si pro dotaz zobrazil execution plan, tak mě na ten chybějící index neupozornil.

Dezadata issue? Páč tam měli takto optimalizovanou aplikaci pro UPC. 10 minut select. Dnes už vím proč nevolat na support UPC. Lidi po 20 minutách třískli telefonem. Jen tak na okraj. Kolega co dělal pro komerčku admina říkal, že by si tam peníze nikdy neuložil. Asi věděl proč. Měli tam jednu databázi a v ní sloupec s popisem: "Nenabízet žádné produkty, reaguje podrážděně". Si fakt nedělám legraci.

Jakýkoliv dotaz z tabulek, které mají do stovek tisíc záznamů a není hotový do sekundy si říká o analýzu a optimalizaci.Zkus si spustit návrháře indexů (ale nenechávej jej nic automaticky vytvářet). A jeho analýzy získáš navržené indexy na základě použití.Pokud máš propojení přes 3 sloupce a uděláš 3 indexy, tak nic nezískáš. Zrychlilo se ti to, protože použil index na tom třetím sloupci a předtím dělal full scan. Pomohl by ti jeden index přes všechny 3 sloupce.Další věc je omezení pomocí custerovaného indexu. Pokud máš cluster na datum a víš, že záznamy nemohou být staší než měsíc, omez to pro jistotu na 2 měsíce do minulosti.

Co můžeš udělat dnes, odlož na včerejšek.

Ještě, pokud si zobrazuješ execution plan, tak tam vydíš přímo náklady na jednotlivé kroky a víš, co konkrétně zdržuje.

Co můžeš udělat dnes, odlož na včerejšek.

ten index jsem samozřejmě vyrobil přes všechny tři sloupce, to je jasný a ten execution plán - u něj mě právě zarazilo, že ty náklady byly rovnoměrně rozložený mezi všechny prováděné vazby (těch vazeb je tam celkem 8) a nebyly nijak zvětšené u té vazby, kde mi chyběl index, proto jsem psal, že je zvláštní, že jsem s jeho pomocí ten chybějící index nenašel

Dotaz pres 100 000 zaznamu musi byt hotovy okamzite bez cekani - v pripade, ze je to dotaz, ktery se pouziva casteji. Pokud trva dele, musis dal pokracovat v optimalizaci.

Co můžeš udělat dnes, odlož na včerejšek.