Sdílet prostřednictvím

Statistika

platí pro:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse Analyticssql database v Microsoft Fabric

Optimalizátor dotazů používá statistiky k vytváření plánů dotazů, které zlepšují výkon dotazů. U většiny dotazů už Optimalizátor dotazů generuje potřebné statistiky pro vysoce kvalitní plán dotazů; v některých případech je potřeba vytvořit další statistiky nebo upravit návrh dotazu pro nejlepší výsledky. Tento článek popisuje koncepty statistik a poskytuje pokyny k efektivnímu používání statistik optimalizace dotazů.

Komponenty a koncepty

Statistika

Statistika optimalizace dotazů jsou binární velké objekty (BLOB), které obsahují statistické informace o rozdělení hodnot v jednom nebo více sloupcích tabulky nebo indexovaného zobrazení. Optimalizátor dotazů používá tyto statistiky k odhadu kardinality nebo počtu řádků ve výsledku dotazu. Tyto odhady kardinality umožňují optimalizátoru dotazů vytvořit vysoce kvalitní plán dotazů. Například v závislosti na vašich predikátech může optimalizátor dotazů použít odhady kardinality k výběru operátoru prohledávání indexu místo operátoru náročného na prostředky při prohledávání indexu, pokud tím zlepšíte výkon dotazů.

Každý objekt statistiky se vytvoří v seznamu jednoho nebo více sloupců tabulky a obsahuje histogram zobrazující rozdělení hodnot v prvním sloupci. Statistické objekty ve více sloupcích také ukládají statistické informace o korelaci hodnot mezi sloupci. Tyto korelační statistiky nebo hustoty jsou odvozeny z počtu jedinečných řádků hodnot sloupců.

Histogram

Histogram měří četnost výskytů pro každou jedinečnou hodnotu v sadě dat. Optimalizátor dotazů vypočítá histogram hodnot sloupců v prvním klíčovém sloupci objektu statistiky a vybere hodnoty sloupců statisticky vzorkováním řádků nebo provedením úplné kontroly všech řádků v tabulce nebo zobrazení. Pokud se histogram vytvoří ze vzorek sady řádků, uložené součty pro počet řádků a počet jedinečných hodnot jsou odhady a nemusí být celá celá čísla.

Note

Histogramy v SQL Serveru jsou vytvořeny pouze pro jeden sloupec - první sloupec v sadě klíčových sloupců objektu statistiky.

Pokud chcete vytvořit histogram, optimalizátor dotazů seřadí hodnoty sloupců, vypočítá počet hodnot, které odpovídají každé jedinečné hodnotě sloupce, a pak agreguje hodnoty sloupců do maximálně 200 souvislých kroků histogramu. Každý krok histogramu zahrnuje oblast hodnot sloupců následovanou hodnotou horního vázaného sloupce. Oblast zahrnuje všechny možné hodnoty sloupců mezi hodnotami hranic, s výjimkou samotných hodnot hranic. Nejnižší z hodnot seřazených sloupců je horní hraniční hodnota prvního kroku histogramu.

Sql Server vytvoří histogram z seřazené sady hodnot sloupců ve třech krocích:

  • Inicializace histogramu: V prvním kroku se zpracuje posloupnost hodnot začínající na začátku seřazené sady a až 200 hodnot range_high_key, equal_rows, range_rows a distinct_range_rows (range_rows a distinct_range_rows jsou v tomto kroku vždy nula). První krok končí buď při vyčerpání všech vstupů, nebo při zjištění 200 hodnot.
  • Prohledávání s sloučením kbelíků: Každá další hodnota z úvodního sloupce klíče statistiky se zpracuje v druhém kroku v seřazeném pořadí; každá následná hodnota se buď přičte k poslednímu rozsahu, nebo se vytvoří nová oblast na konci (je to možné, protože vstupní hodnoty jsou seřazené). Pokud je vytvořen nový rozsah, jedna dvojice existujících, sousedících rozsahů se sloučí do jednoho rozsahu. Tato dvojice rozsahů je vybrána, aby se minimalizovala ztráta informací. Tato metoda používá algoritmus maximálního rozdílu k minimalizaci počtu kroků v histogramu při maximalizaci rozdílu mezi hodnotami hranic. Počet kroků po sbalení rozsahů zůstává po celou dobu tohoto kroku na 200.
  • Konsolidace histogramu: Ve třetím kroku je možné sloučit více oblastí, pokud se neztratí podstatné množství informací. Počet kroků histogramu může být menší než počet jedinečných hodnot, a to i u sloupců s méně než 200 hraničními body. Proto i v případě, že sloupec obsahuje více než 200 jedinečných hodnot, může mít histogram méně než 200 kroků. Pro sloupec, který se skládá pouze z jedinečných hodnot, má konsolidovaný histogram minimálně tři kroky.

Note

Pokud byl histogram sestaven pomocí vzorku místo úplného prohledání, pak se odhadují hodnoty equal_rows, range_rows a distinct_range_rows a average_range_rows , a proto nemusí být celá celá čísla.

Následující diagram znázorňuje histogram se šesti kroky. Oblast vlevo od první hodnoty horní hranice je prvním krokem.

diagramu výpočtu histogramu z hodnot vzorek sloupce

Pro každý krok histogramu v předchozím příkladu:

  • Tučná linka zobrazuje hodnotu horní hranice (range_high_key) a počet výskytů (equal_rows)

  • Plná oblast vlevo od range_high_key představuje rozsah hodnot sloupců a průměrný počet výskytů každé hodnoty sloupce (average_range_rows). average_range_rows pro první krok histogramu je vždy 0.

  • Tečkované čáry představují hodnoty vzorku použité k odhadu celkového počtu jedinečných hodnot v oblasti (distinct_range_rows) a celkového počtu hodnot v oblasti (range_rows). Optimalizátor dotazů používá range_rows a distinct_range_rows k výpočtu average_range_rows a neukládá vzorkované hodnoty.

Vektor hustoty

Hustota je informace o počtu duplicit v daném sloupci nebo kombinaci sloupců a vypočítá se jako 1/(počet jedinečných hodnot). Optimalizátor dotazů používá hustoty k vylepšení odhadů kardinality pro dotazy, které vracejí více sloupců ze stejné tabulky nebo indexovaného zobrazení. S poklesem hustoty se selektivita hodnoty zvyšuje. Například v tabulce představující auta má mnoho automobilů stejný výrobce, ale každé auto má jedinečné identifikační číslo vozidla (VIN). Index na VIN je selektivnější než index na výrobce, protože VIN má nižší hustotu než výrobce.

Note

Frekvence je informace o výskytu každé jedinečné hodnoty v prvním klíčovém sloupci objektu statistiky a je vypočítán jako row count * density. Maximální četnost 1 najdete ve sloupcích s jedinečnými hodnotami.

Vektor hustoty obsahuje jednu hustotu pro každou předponu sloupců v objektu statistiky. Pokud má například objekt statistiky klíčové sloupce CustomerId, ItemId a Price, hustota se vypočítá na každé z následujících předpon sloupců.

Předpona sloupce Hustota vypočítaná na
()CustomerId Řádky s odpovídajícími hodnotami pro CustomerId
(CustomerId, ItemId) Řádky s odpovídajícími hodnotami pro CustomerId a ItemId
(CustomerId, ItemId, Price) Řádky s odpovídajícími hodnotami pro CustomerId, ItemIda Price

Filtrované statistiky

Filtrované statistiky můžou zlepšit výkon dotazů pro dotazy, které vybírají z dobře definovaných podmnožina dat. Filtrované statistiky používají predikát filtru k výběru podmnožina dat, která jsou součástí statistiky. Dobře navržené filtrované statistiky můžou vylepšovat plán provádění dotazů ve srovnání se statistikami úplné tabulky. Další informace o predikátu filtru naleznete v tématu CREATE STATISTICS. Další informace o tom, kdy vytvořit filtrované statistiky, naleznete v části Kdy vytvořit statistiky v tomto článku.

Možnosti statistiky

Existují možnosti, které ovlivňují, kdy a jak se vytvářejí a aktualizují statistiky. Tyto možnosti lze konfigurovat pouze na úrovni databáze.

možnost AUTO_CREATE_STATISTICS

Pokud je možnost automatického vytvoření statistiky, AUTO_CREATE_STATISTICS zapnuto, optimalizátor dotazů vytvoří statistiky o jednotlivých sloupcích v predikáte dotazu podle potřeby, aby se zlepšily odhady kardinality pro plán dotazu. Tyto statistiky s jedním sloupcem se vytvářejí ve sloupcích, které ještě nemají histogram v existujícím objektu statistiky. Možnost AUTO_CREATE_STATISTICS neurčí, jestli se pro indexy vytvoří statistika. Tato možnost také negeneruje filtrované statistiky. Platí výhradně pro statistiky s jedním sloupcem pro celou tabulku.

Když optimalizátor dotazů vytvoří statistiku v důsledku použití AUTO_CREATE_STATISTICS, název statistiky začíná na _WA. Pomocí následujícího dotazu můžete určit, jestli optimalizátor dotazů vytvořil statistiku pro sloupec predikátu dotazu.

SELECT OBJECT_NAME(s.object_id) AS object_name,
    COL_NAME(sc.object_id, sc.column_id) AS column_name,
    s.name AS statistics_name
FROM sys.stats AS s
    INNER JOIN sys.stats_columns AS sc
        ON s.stats_id = sc.stats_id
        AND s.object_id = sc.object_id
WHERE s.name LIKE '_WA%'
ORDER BY s.name;

možnost AUTO_UPDATE_STATISTICS

Pokud je možnost automatická aktualizace statistik, AUTO_UPDATE_STATISTICS zapnutá, optimalizátor dotazů určí, kdy statistiky mohou být zastaralé, a aktualizuje je, když je dotaz používá. Tato akce se také označuje jako rekompilace statistik. Statistiky se stanou zastaralými po úpravách operací vložení, aktualizace, odstranění nebo sloučení, které změní distribuci dat v tabulce nebo indexovaném zobrazení. Optimalizátor dotazů určuje, kdy statistiky můžou být zastaralé, počítáním počtu úprav řádků od poslední aktualizace statistiky a porovnáním počtu úprav řádků s prahovou hodnotou. Prahová hodnota je založená na kardinalitě tabulky, kterou lze definovat jako počet řádků v tabulce nebo indexované zobrazení.

Při označování statistik jako zastaralých na základě úprav řádků dochází i v případě, že AUTO_UPDATE_STATISTICS je tato možnost vypnutá. AUTO_UPDATE_STATISTICS Pokud je tato možnost vypnutá, statistiky se neaktualizují, i když jsou označené jako zastaralé. Plány nadále používají zastaralé objekty statistiky. Nastavení AUTO_UPDATE_STATISTICS na vypnuto může způsobit neoptimální plány dotazů a snížení výkonu dotazů. AUTO_UPDATE STATISTICS Doporučujeme nastavit možnost ZAPNUTO.

  • Databázový stroj používá až SQL Server 2014 (12.x) prahovou hodnotu rekompilace na základě počtu řádků v tabulce nebo indexovaném zobrazení v době vyhodnocení statistiky. Prahová hodnota se liší bez ohledu na to, jestli je tabulka dočasná nebo trvalá.

    Typ tabulky Kardinalita tabulky (n) Prahová hodnota překompilace (počet úprav)
    Temporary n< 6 6
    Temporary 6 <= n<= 500 500
    Permanent N<= 500 500
    Dočasné nebo trvalé n> 500 500 + (0,20 * n)

    Pokud například tabulka obsahuje 20 tisíc řádků, výpočet je 500 + (0.2 * 20,000) = 4,500 a statistika se aktualizuje každých 4 500 úprav.

  • Počínaje SQL Serverem 2016 (13.x) a úrovní kompatibility databáze 130 používá databázový stroj také snížení prahové hodnoty rekompilace dynamických statistik, které se v době vyhodnocení statistiky upraví podle kardinality tabulky. Při této změně se statistiky velkých tabulek aktualizují častěji. Pokud má však databáze úroveň kompatibility nižší než 130, použijí se prahové hodnoty SQL Serveru 2014 (12.x).

    Typ tabulky Kardinalita tabulky (n) Prahová hodnota překompilace (počet úprav)
    Temporary n < 6 6
    Temporary 6 <= n <= 500 500
    Permanent n <= 500 500
    Dočasné nebo trvalé n > 500 MIN ( 500 + (0.20 * n), SQRT(1,000 * n) )

    Pokud například tabulka obsahuje 2 miliony řádků, pak je výpočet minimem z 500 + (0.20 * 2,000,000) = 400,500 a SQRT(1,000 * 2,000,000) = 44,721. To znamená, že statistiky se aktualizují každých 44 721 úprav.

Important

Ve SQL Serveru 2008 R2 (10.50.x) až SQL Serveru 2014 (12.x) nebo SQL Serveru 2016 (13.x) a novějších verzích s úrovní kompatibility databáze 120 a nižšími verzemi povolte trace flag 2371, aby SQL Server používal snižující se dynamický práh pro aktualizaci statistik.

Zapnutí příznaku trasování 2371 je volitelné, přestože se doporučuje pro všechny scénáře. Můžete ale použít následující pokyny pro povolení příznaku trasování 2371 ve verzi před SQL Serverem 2016 (13.x):

  • Pokud používáte systém SAP, povolte toto trasování. Další informace najdete v blogu o trasovacím příznaku 2371.
  • Pokud je třeba, abyste se při aktualizaci statistik spoléhal na noční úlohu, jelikož aktuální automatická aktualizace se nespouští často, zvažte povolení sledovacího příznaku 2371 pro úpravu prahové hodnoty kardinality tabulky.

Optimalizátor dotazů před kompilací dotazu a před spuštěním plánu dotazů v mezipaměti vyhledá zastaralé statistiky. Před kompilací dotazu použije Optimalizátor dotazů sloupce, tabulky a indexovaná zobrazení v predikáte dotazu k určení, které statistiky mohou být zastaralé. Než spustí plán dotazů uložený v mezipaměti, databázový stroj ověří, že plán dotazu odkazuje na up-tostatistiku data.

Možnost AUTO_UPDATE_STATISTICS se vztahuje na objekty statistik vytvořené pro indexy, jednosloupcové predikáty dotazu a statistiky vytvořené pomocí příkazu CREATE STATISTICS . Tato možnost platí také pro filtrované statistiky.

Pomocí sys.dm_db_stats_properties můžete přesně sledovat počet řádků, které se v tabulce změnily, a rozhodnout se, jestli chcete statistiky aktualizovat ručně.

AUTO_UPDATE_STATISTICS je pro tabulky optimalizované pro paměť vždy vypnuté.

AUTO_UPDATE_STATISTICS_ASYNC

Možnost aktualizace asynchronní statistiky AUTO_UPDATE_STATISTICS_ASYNC určuje, jestli optimalizátor dotazů používá synchronní nebo asynchronní aktualizace statistik. Ve výchozím nastavení je asynchronní aktualizace statistik vypnutá a optimalizátor dotazů aktualizuje statistiky synchronně. Možnost AUTO_UPDATE_STATISTICS_ASYNC se vztahuje na objekty statistik vytvořené pro indexy, jednotlivé sloupce v predikátech dotazů a statistiky vytvořené pomocí příkazu CREATE STATISTICS .

Note

Chcete-li nastavit možnost asynchronní aktualizace statistik v aplikaci SQL Server Management Studio, musí být na stránce Možnosti okna Vlastnosti databáze nastaveny možnosti Automatická aktualizace statistik i Automatická aktualizace statistik asynchronně na True.

Aktualizace statistik můžou být buď synchronní (výchozí), nebo asynchronní.

  • Díky synchronním aktualizacím statistiky se dotazy vždy kompilují a spouštějí pomocí statistiky up-to-date. Pokud jsou statistiky zastaralé, optimalizátor dotazů před kompilací a spuštěním dotazu čeká na aktualizované statistiky.

  • Díky asynchronním aktualizacím statistik se dotazy kompilují s existujícími statistikami, i když jsou stávající statistiky zastaralé. Optimalizátor dotazů může zvolit neoptimální plán dotazu, pokud jsou statistiky při kompilaci dotazu zastaralé. Statistiky se obvykle brzy aktualizují. Dotazy, které se kompilují po dokončení aktualizací statistik, můžou využívat aktualizované statistiky.

Při provádění operací, které mění distribuci dat, například zkrácení tabulky nebo hromadné aktualizace velkého procenta řádků, zvažte použití synchronních statistik. Pokud statistiku po dokončení operace ručně neaktualizujete, pomocí synchronních statistik zajistíte, že statistiky budou aktuální před provedením dotazů na změněná data up-to.

Zvažte použití asynchronních statistik k dosažení předvídatelnější doby odezvy dotazů pro následující scénáře:

  • Vaše aplikace často spouští stejný dotaz, podobné dotazy nebo podobné plány dotazů v mezipaměti. Doby odezvy dotazů můžou být předvídatelnější díky asynchronním aktualizacím statistik než u synchronních aktualizací statistik, protože Optimalizátor dotazů může spouštět příchozí dotazy bez čekání na up-tostatistiku data. Tím se zabrání zpoždění některých dotazů a ne jiných.

  • U vaší aplikace došlo k vypršení časového limitu požadavků klienta způsobených jedním nebo více dotazy čekajícími na aktualizované statistiky. V některých případech může čekání na synchronní statistiky způsobit selhání aplikací s agresivními časovými limity.

Note

Statistiky místních dočasných tabulek se vždy aktualizují synchronně bez ohledu na možnost AUTO_UPDATE_STATISTICS_ASYNC. Statistiky globálních dočasných tabulek se aktualizují synchronně nebo asynchronně podle možnosti AUTO_UPDATE_STATISTICS_ASYNC nastavené pro uživatelskou databázi.

Asynchronní aktualizace statistik se provádí požadavkem na pozadí. Když je požadavek připravený k zápisu aktualizovaných statistik do databáze, pokusí se získat zámek úprav schématu objektu metadat statistiky. Pokud již jiná relace drží zámek na stejném objektu, nelze provést asynchronní aktualizaci statistiky, dokud nebude možné získat zámek úprav schématu. Podobně relace, které potřebují získat zámek na objekt metadat statistiky pro stabilitu schématu (Sch-S) aby mohly zkompilovat dotaz, mohou být blokovány asynchronní relací aktualizace statistik na pozadí, která již drží nebo čeká na získání zámku pro změnu schématu. Proto u úloh s velmi častými kompilacemi dotazů a častými aktualizacemi statistik může použití asynchronních statistik zvýšit pravděpodobnost problémů souběžnosti kvůli blokování zámku.

V Azure SQL Database, Azure SQL Managed Instance a počínaje SQL Serverem 2022 (16.x) se můžete vyhnout potenciálním problémům se souběžností pomocí asynchronní aktualizace statistik, pokud povolíte konfiguraci s rozsahem databáze ASYNC_STATS_UPDATE_WAIT_AT_LOW_PRIORITY. Když je tato konfigurace povolená, požadavek na pozadí čeká na získání zámku schématu (Sch-M) a zachování aktualizovaných statistik v samostatné frontě s nízkou prioritou, což ostatním požadavkům umožní pokračovat ve kompilaci dotazů s existujícími statistikami. Jakmile žádná jiná relace neudržuje zámek objektu metadat statistiky, požadavek na pozadí získá zámek změny schématu a aktualizuje statistiky. V nepravděpodobném případě, že požadavek na pozadí nemůže získat zámek během časového limitu několika minut, asynchronní aktualizace statistiky se přeruší a statistiky se neaktualizují, dokud se neaktivuje jiná automatická aktualizace statistiky nebo dokud se statistiky neaktualizují ručně.

Note

Možnost konfigurace s rozsahem ASYNC_STATS_UPDATE_WAIT_AT_LOW_PRIORITY databáze je dostupná ve službě Azure SQL Database, Azure SQL Managed Instance a na SQL Serveru počínaje SQL Serverem 2022 (16.x).

možnost AUTO_DROP

Platí pro: Azure SQL Database, Azure SQL Managed Instance a počínaje SQL Serverem 2022 (16.x)

Pokud jsou statistiky ručně vytvořeny uživatelem nebo nástrojem třetí strany v uživatelské databázi před SQL Serverem 2022 (16.x), můžou tyto statistické objekty blokovat nebo kolidovat se změnami schématu, které byste mohli chtít.

Počínaje SQL Serverem 2022 (16.x) je ve výchozím nastavení povolená možnost automatického odstraňování pro všechny nové a migrované databáze. Tato AUTO_DROP vlastnost umožňuje vytváření statistických objektů v režimu tak, aby následná změna schématu nebyla objektem statistiky blokována, ale statistika se podle potřeby zahodí. Tímto způsobem se ručně vytvořené statistiky s povoleným automatickým přetažením chovají jako automaticky vytvořené statistiky.

Ve službě Azure SQL Database, Azure SQL Managed Instance a SQL Serveru 2022 (16.x) a novějších verzích se automaticky vytvářejí statistiky, jako by byla nastavena AUTO_DROP .

Note

Při pokusu o nastavení nebo zrušení vlastnosti automatického přetažení u automaticky vytvořených statistik můžou vzniknout chyby. Automaticky vytvořené statistiky vždy používají automatické odstraňování. Některé zálohy při obnovení můžou tuto vlastnost nastavit nesprávně, dokud se příště neaktualizuje objekt statistiky (ručně nebo automaticky). Automaticky vytvořené statistiky se ale vždy chovají jako automatické poklesy statistiky. Při obnovování databáze na SQL Server 2022 (16.x) z předchozí verze se doporučuje provést sp_updatestats v databázi a nastavit správná metadata pro funkci automatického odstraňování statistik.

Pokud chcete například ručně vytvořit objekt statistiky v dbo.DatabaseLog tabulce:

CREATE STATISTICS [mystats]
    ON [dbo].[DatabaseLog]([DatabaseLogID], [PostTime], [DatabaseUser])
    WITH AUTO_DROP = ON;

Pokud chcete například aktualizovat nastavení automatického přetažení objektu statistiky v dbo.DatabaseLog tabulce:

UPDATE STATISTICS [dbo].[DatabaseLog] ([mystats])
    WITH AUTO_DROP = ON;

Pokud chcete vyhodnotit nastavení automatického odstraňování existujících statistik, použijte auto_drop sloupec v sys.stats:

SELECT object_id,
       [name],
       auto_drop
FROM sys.stats;

Další informace najdete v tématu AUTO_DROP.

INCREMENTAL

platí pro: SQL Server 2014 (12.x) a novější verze.

Pokud je možnost PŘÍRŮSTKOVÉ VYTVOŘENÍ STATISTIKY ZAPNUTÁ, statistiky se vytvářejí pro každý oddíl zvlášť. Při vypnutí se statistické údaje odstraní a SQL Server statistiku znovu zkompiluje. Výchozí hodnota je VYPNUTÁ. Toto nastavení přepíše vlastnost INCREMENTAL na úrovni databáze. Další informace o vytváření přírůstkových statistik naleznete v tématu VYTVOŘENÍ STATISTIKY. Další informace o automatickém vytváření statistik jednotlivých oddílů naleznete v tématech Vlastnosti databáze (stránka Možnosti) a ALTER DATABASE SET možnosti.

Při přidání nových oddílů do velké tabulky by se měly aktualizovat statistiky tak, aby zahrnovaly nové oddíly. Doba potřebná ke kontrole celé tabulky (FULLSCAN nebo SAMPLE možností) však může být poměrně dlouhá. Skenování celé tabulky není nutné, protože mohou být potřeba pouze statistiky o nových oddílech. Přírůstková možnost vytváří a ukládá statistiky na základě jednotlivých oddílů a při aktualizaci aktualizuje pouze statistiky těchto oddílů, které potřebují nové statistiky.

Pokud statistiky jednotlivých oddílů nejsou podporované, možnost se ignoruje a vygeneruje se upozornění. Přírůstkové statistiky nejsou podporované pro následující typy statistik:

  • Statistiky vytvořené s indexy, které nejsou v souladu se základní tabulkou
  • Statistiky vytvořené v sekundárních databázích s možností čtení AlwaysOn
  • Statistiky vytvořené pro databáze jen pro čtení
  • Statistiky vytvořené pro filtrované indexy
  • Statistiky vytvořené v zobrazeních
  • Statistiky vytvořené v interních tabulkách
  • Statistiky vytvořené pomocí prostorových indexů nebo indexů XML

Kdy vytvořit statistiku

Optimalizátor dotazů již vytváří statistiky následujícími způsoby:

  1. Optimalizátor dotazů vytvoří statistiky pro indexy v tabulkách nebo zobrazeních při vytváření indexu. Tyto statistiky se vytvářejí na klíčových sloupcích indexu. Pokud je index filtrovaný index, optimalizátor dotazů vytvoří filtrované statistiky pro stejnou podmnožinu řádků zadaných pro filtrovaný index. Další informace o filtrovaných indexech naleznete v tématu Vytvoření filtrovaných indexů a CREATE INDEX.

    Note

    Ve verzích SQL Server 2014 (12.x) a novějších se statistiky nevytvářejí prohledáváním všech řádků v tabulce při vytváření nebo obnovení děleného indexu. Místo toho optimalizátor dotazů používá k vygenerování statistik výchozí algoritmus vzorkování. Po upgradu databáze s dělenými indexy si můžete všimnout rozdílu v datech histogramu pro tyto indexy. Tato změna chování nemusí ovlivnit výkon dotazů. Pokud chcete získat statistiky o dělených indexech prohledáváním všech řádků v tabulce, použijte CREATE STATISTICS nebo UPDATE STATISTICS s klauzulí FULLSCAN.

  2. Optimalizátor dotazů vytváří statistiky pro jednotlivé sloupce v predikátech dotazů, když je AUTO_CREATE_STATISTICS zapnutý.

U většiny dotazů tyto dvě metody vytváření statistik zajišťují vysoce kvalitní plán dotazů; V několika případech můžete plány dotazů vylepšit vytvořením dalších statistik pomocí příkazu CREATE STATISTICS . Tyto další statistiky můžou zaznamenávat statistické korelace, které optimalizátor dotazů nebere v úvahu při vytváření statistik pro indexy nebo jednotlivé sloupce. Aplikace může mít v datech tabulky další statistické korelace, které by při výpočtu do objektu statistiky mohly optimalizátoru dotazů zlepšit plány dotazů. Filtrované statistiky pro podmnožinu řádků dat nebo vícesloupcové statistiky ve sloupcích predikátu dotazu můžou plán dotazu vylepšit.

Při vytváření statistik pomocí příkazu CREATE STATISTICS doporučujeme zachovat AUTO_CREATE_STATISTICS možnost ZAPNUTO, aby optimalizátor dotazů stále vytvářel statistiky s jedním sloupcem pro predikát dotazu. Další informace o predikátech dotazů najdete v tématu Podmínka hledání.

Pokud platí některá z následujících možností, zvažte vytvoření statistik pomocí příkazu CREATE STATISTICS:

  • Poradce pro ladění databázového stroje navrhuje vytváření statistik.
  • Predikát dotazu obsahuje více korelačních sloupců, které ještě nejsou klíče ve stejném indexu.
  • Dotaz vybere z podmnožiny dat.
  • Dotaz neobsahuje statistiky.

Note

Informace týkající se In-Memory tabulek a statistik souvisejících s OLTP naleznete v Statistika pro tabulky Memory-Optimized.

Predikát dotazu obsahuje více korelačních sloupců.

Pokud predikát dotazu obsahuje více sloupců, které mají relace mezi sloupci a závislosti, může statistika více sloupců zlepšit plán dotazu. Statistika více sloupců obsahuje statistiky korelace křížového sloupce, označované jako hustoty, které nejsou k dispozici ve statistikách s jedním sloupcem. Hustoty můžou zlepšit odhady kardinality, když výsledky dotazů závisí na relacích mezi daty mezi více sloupci.

Pokud jsou sloupce již ve stejném indexu, objekt vícesloupcové statistiky již existuje a není nutné ho vytvořit ručně. Pokud sloupce ještě nejsou ve stejném indexu, můžete vytvořit vícesloupcové statistiky vytvořením indexu u sloupců nebo pomocí příkazu CREATE STATISTICS . K údržbě indexu je zapotřebí více systémových prostředků než k údržbě objektu statistiky. Pokud aplikace nevyžaduje vícesloupcový index, můžete šetřit systémové prostředky vytvořením objektu statistiky bez vytvoření indexu.

Když vytváříte vícesloupcové statistiky, pořadí sloupců v definici objektu statistiky ovlivňuje efektivitu hustot pro vytváření odhadů kardinality. Objekt statistiky ukládá hustoty pro každou předponu klíčových sloupců v definici objektu statistiky. Další informace o hustotách najdete v části Hustota na této stránce.

Pokud chcete vytvořit hustoty, které jsou užitečné pro odhady kardinality, musí sloupce v predikátu dotazu odpovídat jedné z předpon sloupců v definici objektu statistiky. Například následující příklad vytvoří objekt vícesloupcové statistiky pro sloupce LastName, MiddleNamea FirstName.

USE AdventureWorks2022;
GO

IF EXISTS (SELECT name
           FROM sys.stats
           WHERE name = 'LastFirst'
                 AND object_ID = OBJECT_ID('Person.Person'))
    DROP STATISTICS Person.Person.LastFirst;
GO

CREATE STATISTICS LastFirst
    ON Person.Person(LastName, MiddleName, FirstName);
GO

V tomto příkladu má objekt LastFirst statistiky hustoty pro následující předpony sloupců: (LastName), (LastName, MiddleName)a (LastName, MiddleName, FirstName). Hustota není k dispozici pro (LastName, FirstName). Pokud dotaz používá LastName a FirstName a zároveň nepoužívá MiddleName, hustota není k dispozici pro odhady kardinality.

Výběr dotazu z podmnožiny dat

Když Optimalizátor dotazů vytvoří statistiku pro jednotlivé sloupce a indexy, vytvoří statistiku pro hodnoty ve všech řádcích. Když dotazy vyberou z podmnožinu řádků a tato podmnožina řádků má jedinečnou distribuci dat, filtrované statistiky můžou zlepšit plány dotazů. Filtrované statistiky můžete vytvořit pomocí příkazu CREATE STATISTICS s klauzulí WHERE k definování výrazu predikátu filtru.

Například pomocí AdventureWorks2025 patří každý produkt v Production.Product tabulce do jedné ze čtyř kategorií v Production.ProductCategory tabulce: Bikes, , ComponentsClothinga Accessories. Každá kategorie má jiné rozdělení dat pro hmotnost: hmotnosti kol jsou v rozmezí od 13,77 do 30,0, hmotnosti součástí v rozsahu od 2.12 do 1050.00 s některými NULL hodnotami, váhy oblečení jsou všechny NULLa hmotnosti příslušenství jsou také NULL.

Použití Bikes jako příkladu, filtrované statistiky o všech hmotnostech kol poskytují optimalizátoru dotazů přesnější statistiky a mohou zlepšit kvalitu plánu dotazů v porovnání se statistikami celé tabulky nebo neexistujícími statistikami na sloupci Hmotnost. Sloupec hmotnosti kola je vhodným kandidátem pro filtrované statistiky, ale nemusí nutně být vhodným kandidátem na filtrovaný index, pokud je počet vyhledávání hmotnosti relativně malý. Zvýšení výkonu vyhledávání, které filtrovaný index poskytuje, nemusí převažovat nad dalšími náklady na údržbu a úložiště pro přidání filtrovaného indexu do databáze.

Následující příkaz vytvoří BikeWeights filtrované statistiky pro všechny podkategorie pro Bikes. Filtrovaný predikátový výraz definuje kola výčtem všech podkategorií kol s porovnáním Production.ProductSubcategoryID IN (1,2,3). Predikát nemůže použít Bikes název kategorie, protože je uložený v Production.ProductCategory tabulce a všechny sloupce ve výrazu filtru musí být ve stejné tabulce.

USE AdventureWorks2022;
GO
IF EXISTS ( SELECT name FROM sys.stats
    WHERE name = 'BikeWeights'
    AND object_ID = OBJECT_ID ('Production.Product'))
DROP STATISTICS Production.Product.BikeWeights;
GO
CREATE STATISTICS BikeWeights
    ON Production.Product (Weight)
WHERE ProductSubcategoryID IN (1,2,3);
GO

Optimalizátor dotazů může použít BikeWeights filtrované statistiky ke zlepšení plánu dotazu pro následující dotaz, který vybere všechna kola, která váží více než 25.

SELECT P.Weight AS Weight,
       S.Name AS BikeName
FROM Production.Product AS P
     INNER JOIN Production.ProductSubcategory AS S
         ON P.ProductSubcategoryID = S.ProductSubcategoryID
WHERE P.ProductSubcategoryID IN (1, 2, 3)
      AND P.Weight > 25
ORDER BY P.Weight;
GO

Dotaz identifikuje chybějící statistiky.

Pokud chyba nebo jiná událost brání optimalizátoru dotazů ve vytváření statistik, optimalizátor dotazů vytvoří plán dotazu bez použití statistiky. Optimalizátor dotazů označí statistiku jako chybějící a pokusí se znovu vygenerovat statistiku při příštím spuštění dotazu.

Chybějící statistiky se označují jako upozornění (název tabulky v červeném textu), když se plán provádění dotazu graficky zobrazí pomocí aplikace SQL Server Management Studio. Monitorování třídy událostí Chybějící statistika sloupců navíc pomocí sql Server Profileru indikuje, kdy chybí statistiky. Další informace naleznete v tématu Chyby a varování v kategorizaci událostí (databázový server).

Pokud chybí statistika, proveďte následující kroky:

Dočasná statistika

Pokud chybí statistika databáze jen pro čtení nebo snímek jen pro čtení nebo je zastaralá, databázový stroj vytvoří a udržuje dočasné statistiky v tempdb. Když databázový stroj vytvoří dočasnou statistiku, připojí se název statistiky s příponou _readonly_database_statistic k rozlišení dočasných statistik od trvalých statistik. Přípona _readonly_database_statistic je vyhrazena pro statistiky generované databázovým strojem. Skripty pro dočasnou statistiku je možné vytvořit a spustit v databázi pro čtení i zápis. Při skriptování změní Management Studio příponu názvu statistiky z _readonly_database_statistic na _readonly_database_statistic_scripted.

Dočasné statistiky může vytvářet a aktualizovat pouze databázový stroj. Pomocí stejných nástrojů, které používáte pro trvalé statistiky, ale můžete odstranit dočasné statistiky a monitorovat vlastnosti statistik:

  • Pomocí příkazu DROP STATISTICS odstraňte dočasné statistiky .
  • Monitorovat statistiky pomocí sys.stats a sys.stats_columns zobrazení katalogu. Zobrazení sys.stats systémového is_temporary katalogu obsahuje sloupec, který označuje, které statistiky jsou trvalé a které jsou dočasné.

Vzhledem k tomu, že jsou dočasné statistiky uloženy v tempdb, restartování databázového enginu odebere všechny dočasné statistiky.

Stejně jako u všech statistik vyžaduje i vytvoření a aktualizace dočasných statistik u objektu zámek pro změnu schématu (Sch-M). Tento zámek může blokovat další dotazy a procesy, včetně procesu opětovného spuštění systému na sekundárních replikách, které aplikují transakce z primární repliky. Pokud toto blokování ovlivňuje úlohy dotazů nebo šíření dat, můžete automatické vytváření a aktualizaci dočasných statistik zakázat pomocí READABLE_SECONDARY_TEMPORARY_STATS_AUTO_CREATEREADABLE_SECONDARY_TEMPORARY_STATS_AUTO_UPDATEkonfigurací s vymezeným oborem databáze .

Kdy aktualizovat statistiky

Optimalizátor dotazů určuje, kdy statistiky můžou být zastaralé, a pak je aktualizuje, když jsou potřeba pro plán dotazů. V některých případech můžete plán dotazů vylepšit a zlepšit tak výkon dotazů tím, že aktualizujete statistiky častěji, než když AUTO_UPDATE_STATISTICS zapnuté. Statistiky můžete aktualizovat pomocí UPDATE STATISTICS příkazu nebo uložené procedury sp_updatestats.

Aktualizace statistik zajišťuje, že se dotazy kompilují pomocí statistik up-to-date. Aktualizace statistik prostřednictvím jakéhokoli procesu může způsobit automatické překompilování plánů dotazů. Nedoporučujeme ručně aktualizovat statistiky příliš často, protože mezi vylepšováním plánů dotazů a časem potřebným k rekompilování dotazů existuje kompromis mezi výkonem. Konkrétní kompromisy závisí na vaší aplikaci.

Při aktualizaci statistik pomocí UPDATE STATISTICS nebo sp_updatestatsdoporučujeme zachovat AUTO_UPDATE_STATISTICS nastavenou na zapnuto, aby optimalizátor dotazů pravidelně aktualizoval statistiky.

  • Další informace o tom, jak aktualizovat statistiky pro sloupec, index, tabulku nebo indexované zobrazení, naleznete v tématu AKTUALIZACE STATISTIKY.

  • Informace o tom, jak aktualizovat statistiky pro všechny uživatelem definované a interní tabulky v databázi, naleznete v uložené procedury sp_updatestats.

  • Další informace o prahových hodnotách pro automatické aktualizace statistik najdete v tématu AUTO_UPDATE_STATISTICS Možnost.

Pokud AUTO_UPDATE_STATISTICS je nastavená hodnota VYPNUTO, může se rekompilace plánu stále opakovat z různých jiných důvodů, ale nedochází k nim automaticky kvůli zastaralým aktualizacím statistik. Pokud AUTO_UPDATE_STATISTICS je tato možnost vypnutá, aktualizace statistik probíhají pouze prostřednictvím jiných ručně plánovaných procesů, jako jsou plány údržby. Nastavení AUTO_UPDATE_STATISTICS na vypnuto může proto způsobit neoptimální plány dotazů a snížení výkonu dotazů.

Zjištění zastaralých statistik

Pokud chcete zjistit, kdy byly statistiky naposledy aktualizovány, použijte funkce sys.dm_db_stats_properties nebo STATS_DATE .

Zvažte aktualizaci statistik pro následující podmínky:

  • Časy provádění dotazů jsou pomalé.
  • Operace vložení probíhají ve vzestupných nebo sestupných klíčových sloupcích.
  • Po operacích údržby.

Příklady ruční aktualizace statistik naleznete v tématu AKTUALIZACE STATISTIKY.

Doba provádění dotazů je pomalá

Pokud jsou doby odezvy dotazů pomalé či nepředvídatelné, před provedením dalších kroků při odstraňování problémů se ujistěte, že dotazy mají aktuální statistiku up-to-data.

Operace vložení probíhají ve vzestupných nebo sestupných sloupcích klíčů.

Statistika vzestupných nebo sestupných klíčových sloupců, jako jsou sloupce IDENTITY nebo časového razítka v reálném čase, mohou někdy vyžadovat častější aktualizace statistik, než provádí Optimalizátor dotazů. Operace vložení připojují nové hodnoty ke vzestupným nebo sestupným sloupcům. Počet přidaných řádků může být příliš malý na to, aby vyvolal aktualizaci statistik. Pokud statistiky nejsou up-to-date a dotazy se vyberou z naposledy přidaných řádků, aktuální statistiky pro tyto nové hodnoty nemají odhady kardinality. To může vést k nepřesným odhadům kardinality a pomalému výkonu dotazů.

Například dotaz, který vybere z nejnovějších dat prodejní objednávky, má nepřesné odhady kardinality, pokud se statistiky neaktualizují tak, aby zahrnovaly odhady kardinality pro nejnovější data prodejní objednávky.

Po operacích údržby

Zvažte aktualizaci statistik po provedení postupů údržby, které mění distribuci dat, například zkrácení tabulky nebo hromadné vložení velkého procenta řádků. To může zabránit budoucím zpožděním při zpracování dotazů, zatímco dotazy čekají na automatické aktualizace statistiky.

Operace, jako je opětovné sestavení, defragmentace nebo změna uspořádání indexu, nemění distribuci dat. Proto po provedení operací ALTER INDEX REBUILD, DBCC DBREINDEX, DBCC INDEXDEFRAG nebo ALTER INDEX REORGANIZE nemusíte aktualizovat statistiky . Optimalizátor dotazů aktualizuje statistiky při opětovném sestavení indexu v tabulce nebo zobrazení s ALTER INDEX REBUILD nebo DBCC DBREINDEX, ale tato aktualizace statistik je vedlejším produktem opětovného vytvoření indexu. Optimalizátor dotazů neaktualizuje statistiky po DBCC INDEXDEFRAG ani ALTER INDEX REORGANIZE operacích.

Tip

Počínaje SQL Serverem 2016 (13.x) SP1 CU4 použijte PERSIST_SAMPLE_PERCENT možnost VYTVOŘIT STATISTIKU nebo AKTUALIZOVAT STATISTIKU, pokud chcete nastavit a zachovat konkrétní procento vzorkování pro následné aktualizace statistiky, které explicitně nezadávají procento vzorkování.

Automatická správa indexů a statistik

Inteligentní řešení, jako je například Adaptivní index Defrag, můžete použít k automatické správě defragmentace indexů a aktualizací statistik pro jednu nebo více databází. Tento postup automaticky zvolí, zda se má index znovu sestavit nebo znovu uspořádat podle úrovně fragmentace, mimo jiné parametry, a aktualizovat statistiky lineární prahovou hodnotou.

Dotazy, které efektivně používají statistiky

Některé implementace dotazů, jako jsou místní proměnné a složité výrazy v predikátu dotazu, můžou vést k neoptimálním plánům dotazů. Následující pokyny pro návrh dotazů pro efektivní používání statistik vám můžou pomoct se tomu vyhnout. Další informace o predikátech dotazů najdete v tématu Podmínka hledání.

Plány dotazů můžete vylepšit použitím pokynů pro návrh dotazů, které efektivně používají statistiky ke zlepšení odhadů kardinality pro výrazy, proměnné a funkce používané v predikátech dotazů. Pokud Optimalizátor dotazů nezná hodnotu výrazu, proměnné nebo funkce, neví, kterou hodnotu má vyhledat v histogramu, a proto nemůže načíst nejlepší odhad kardinality z histogramu. Místo toho optimalizátor dotazů zakládá odhad kardinality na průměrný počet řádků na jedinečnou hodnotu pro všechny vzorkované řádky v histogramu. To vede k neoptimálním odhadům kardinality a může poškodit výkon dotazů. Další informace o histogramech najdete v části histogramu na této stránce nebo sys.dm_db_stats_histogram.

Následující pokyny popisují, jak psát dotazy za účelem zlepšení plánů dotazů zlepšením odhadů kardinality.

Vylepšení odhadů kardinality pro výrazy

Pokud chcete zlepšit odhady kardinality pro výrazy, postupujte podle těchto pokynů:

  • Kdykoli je to možné, zjednodušte výrazy s konstantami v nich. Optimalizátor dotazů nevyhodnocuje všechny funkce a výrazy obsahující konstanty před určením odhadů kardinality. Například zjednodušte výraz ABS(-100) na 100.
  • Pokud výraz používá více proměnných, zvažte vytvoření počítaného sloupce pro výraz a pak vytvořte statistiku nebo index vypočítaného sloupce. Predikát WHERE PRICE + Tax > 100 dotazu může mít například lepší odhad kardinality, pokud pro výraz Price + Taxvytvoříte počítaný sloupec .

Vylepšení odhadů kardinality pro proměnné a funkce

Pokud chcete zlepšit odhady kardinality pro proměnné a funkce, postupujte podle těchto pokynů:

  • Pokud predikát dotazu používá místní proměnnou, zvažte přepsání dotazu tak, aby místo místní proměnné používal parametr. Hodnota místní proměnné není známá, když Optimalizátor dotazů vytvoří plán provádění dotazu. Pokud dotaz používá parametr, optimalizátor dotazů použije odhad kardinality pro první skutečnou hodnotu parametru předanou uložené proceduře.

  • Zvažte použití standardní tabulky nebo dočasné tabulky k uložení výsledků funkcí s hodnotami tabulky s více příkazy (mstvf). Optimalizátor dotazů nevytvoří statistiky pro funkce s více příkazy s hodnotami tabulky. Díky tomuto přístupu může Optimalizátor dotazů vytvářet statistiky sloupců tabulky a používat je k vytvoření lepšího plánu dotazů.

  • Zvažte použití standardní nebo dočasné tabulky jako nahrazení proměnné tabulky. Optimalizátor dotazů nevytvoří statistiky pro proměnné tabulky. Díky tomuto přístupu může Optimalizátor dotazů vytvářet statistiky sloupců tabulky a používat je k vytvoření lepšího plánu dotazů. Existují kompromisy při určování, zda použít dočasnou tabulku nebo proměnnou tabulky; Proměnné tabulky používané v uložených procedurách způsobují menší počet rekompilace uložené procedury než dočasné tabulky. V závislosti na aplikaci nemusí použití dočasné tabulky místo proměnné tabulky zvýšit výkon.

  • Pokud uložená procedura obsahuje dotaz, který používá předaný parametr, než použijete parametr v dotazu, neměňte jeho hodnotu v uložené proceduře. Odhady kardinality dotazu jsou založené na předané hodnotě parametru, nikoli na aktualizované hodnotě. Pokud se chcete vyhnout změně hodnoty parametru, můžete dotaz přepsat tak, aby používal dvě uložené procedury.

    Například následující uložená procedura Sales.GetRecentSales změní hodnotu parametru @date , pokud @date je NULL.

    USE AdventureWorks2022;
GO

IF OBJECT_ID('Sales.GetRecentSales', 'P') IS NOT NULL
    DROP PROCEDURE Sales.GetRecentSales;
GO

CREATE PROCEDURE Sales.GetRecentSales
@date DATETIME
AS
BEGIN
    IF @date IS NULL
        SET @date = DATEADD(MONTH, -3,
            (SELECT MAX(ORDERDATE)
            FROM Sales.SalesOrderHeader));
    SELECT *
    FROM Sales.SalesOrderHeader AS h, Sales.SalesOrderDetail AS d
    WHERE h.SalesOrderID = d.SalesOrderID
        AND h.OrderDate > @date;
END
GO

    Pokud první volání uložené procedury Sales.GetRecentSales předá NULL pro parametr @date, optimalizátor dotazů zkompiluje uloženou proceduru s odhadem kardinality pro @date = NULL, i když predikát dotazu není volán s @date = NULL. Tento odhad kardinality se může výrazně lišit od počtu řádků ve skutečném výsledku dotazu. V důsledku toho může optimalizátor dotazů zvolit neoptimální plán dotazů. Abyste tomu předešli, můžete uloženou proceduru přepsat do dvou procedur následujícím způsobem:

    USE AdventureWorks2022;
GO

IF OBJECT_ID('Sales.GetNullRecentSales', 'P') IS NOT NULL
    DROP PROCEDURE Sales.GetNullRecentSales;
GO

CREATE PROCEDURE Sales.GetNullRecentSales
@date DATETIME
AS
BEGIN
    IF @date IS NULL
        SET @date = DATEADD(MONTH, -3,
            (SELECT MAX(ORDERDATE)
            FROM Sales.SalesOrderHeader));
    EXECUTE Sales.GetNonNullRecentSales @date;
END
GO

IF OBJECT_ID('Sales.GetNonNullRecentSales', 'P') IS NOT NULL
    DROP PROCEDURE Sales.GetNonNullRecentSales;
GO

CREATE PROCEDURE Sales.GetNonNullRecentSales
@date DATETIME
AS
BEGIN
    SELECT *
    FROM Sales.SalesOrderHeader AS h, Sales.SalesOrderDetail AS d
    WHERE h.SalesOrderID = d.SalesOrderID
        AND h.OrderDate > @date;
END
GO

Vylepšení odhadů kardinality pomocí tipů pro dotazy

Chcete-li zlepšit odhady kardinality pro místní proměnné, můžete použít OPTIMIZE FOR <value> nebo OPTIMIZE FOR UNKNOWN dotazové tipy s RECOMPILE. Další informace najdete v tématu nápovědy k dotazům.

U některých aplikací může překompilování dotazu pokaždé, když se spustí, trvat příliš dlouho. Podnět dotazu OPTIMIZE FOR může pomoci i v případě, že tuto možnost RECOMPILE nepoužíváte. Do uložené procedury OPTIMIZE FOR můžete například přidat Sales.GetRecentSales možnost pro zadání konkrétního data. Následující příklad přidá OPTIMIZE FOR možnost do Sales.GetRecentSales procedury.

USE AdventureWorks2022;
GO

IF OBJECT_ID('Sales.GetRecentSales', 'P') IS NOT NULL
    DROP PROCEDURE Sales.GetRecentSales;
GO

CREATE PROCEDURE Sales.GetRecentSales
@date DATETIME
AS
BEGIN
    IF @date IS NULL
        SET @date = DATEADD(MONTH, -3,
            (SELECT MAX(ORDERDATE)
            FROM Sales.SalesOrderHeader));
    SELECT *
    FROM Sales.SalesOrderHeader AS h, Sales.SalesOrderDetail AS d
    WHERE h.SalesOrderID = d.SalesOrderID AND h.OrderDate > @date
    OPTION (OPTIMIZE FOR (@date = '2004-05-01 00:00:00.000'));
END
GO

Vylepšení odhadů kardinality pomocí průvodců plánů

U některých aplikací se pokyny k návrhu dotazů nemusí použít, protože dotaz nemůžete změnit nebo nápovědu RECOMPILE k dotazu může způsobit příliš mnoho rekompilů. Pomocí průvodců plánem můžete určit další rady, například USE PLAN, k řízení chování dotazu při zkoumání změn aplikace u dodavatele aplikace. Další informace o průvodcích plánem najdete v tématu Průvodci plánem.

Ve službě Azure SQL Database zvažte použití nápověd úložiště dotazů k vynucení plánů, místo použití plánovacích průvodců. Další informace najdete v části Tipy pro úložiště dotazů.

Související obsah

  • Last updated on