Funkce inteligentního zpracování dotazů podrobně

Platí pro:SQL ServerAzure SQL DatabaseSpravovaná instance Azure SQLDatabáze SQL v Microsoft Fabric

Tento článek obsahuje podrobné popisy různých funkcí inteligentního zpracování dotazů (IQP), poznámek k verzi a dalších podrobností. Řada funkcí inteligentního zpracování dotazů (IQP) zahrnuje funkce s širokým dopadem, které zlepšují výkon stávajících úloh s minimálním úsilím implementace, které je potřeba přijmout.

Úlohy můžete automaticky využít k inteligentnímu zpracování dotazů povolením příslušné úrovně kompatibility databáze pro databázi. Můžete to nastavit pomocí jazyka Transact-SQL. Pokud chcete například nastavit úroveň kompatibility databáze na SQL Server 2022 (16.x):

ALTER DATABASE [WideWorldImportersDW]
    SET COMPATIBILITY_LEVEL = 160;

Další informace o změnách zavedených s novými verzemi najdete zde:

• Novinky v SQL Serveru 2025
• Novinky v SQL Serveru 2022
• Novinky v SQL Serveru 2019
• Novinky v SQL Serveru 2017

Adaptivní spojení v režimu Batch

Platí pro: SQL Server (počínaje SQL Serverem 2017 (14.x)), Azure SQL Database

Funkce Adaptivních Spojení v dávkovém režimu umožňuje odložení volby metody hash join nebo nested loops join až po naskenování prvního vstupu, a to použitím jednoho plánu v mezipaměti. Operátor adaptivního spojení definuje prahovou hodnotu, která se používá k rozhodnutí o přechodu na plán vnořených smyček. Váš plán se proto může dynamicky přepnout na lepší strategii propojení během provádění.

Další informace, včetně toho, jak zakázat adaptivní spojení beze změny úrovně kompatibility, najdete v tématu Vysvětlení adaptivních spojení.

Prokládané zpracování pro MSTVFs

Platí pro: SQL Server (počínaje SQL Serverem 2017 (14.x)), Azure SQL Database

Funkce MSTVF (Multi-statement table-valued) je typ uživatelem definované funkce, která může přijímat parametry, spouštět více příkazů T-SQL a RETURN tabulku.

Prokládané provádění pomáhá řešit problémy s výkonem zátěže, které jsou způsobeny pevnými odhady kardinality spojenými s MSTVFs. Při prokládání provádění se skutečné počty řádků z funkce používají k činění lépe informovaných rozhodnutí týkajících se následného plánu dotazů.

MSTVFs má pevný odhad kardinality 100 počínaje SQL Serverem 2014 (12.x) a 1 pro starší verze SQL Serveru.

Prokládání provádění mění jednosměrnou hranici mezi fázemi optimalizace a provádění pro provádění s jedním dotazem a umožňuje plánům přizpůsobit se na základě revidovaných odhadů kardinality. Pokud databázový stroj při optimalizaci narazí na kandidáta na prokládání provádění, které používá funkce s více příkazy s hodnotami tabulky (MSTVFs), optimalizace se pozastaví, spustí příslušné podstromy, zachytí přesné odhady kardinality a pak obnoví optimalizaci podřízených operací.

Následující obrázek znázorňuje výstup statistiky živého dotazu , podmnožinu celkového plánu provádění, který ukazuje dopad pevných odhadů kardinality z MSTVF.

Uvidíte skutečný tok řádků vs. odhadované řádky. Plán má tři důležité oblasti (tok je zprava doleva):

• Skenování tabulky MSTVF má pevný odhad 100 řádků. V tomto příkladu však existuje 527 597 řádků procházejících touto kontrolou tabulky MSTVF, jak je vidět ve statistikách živého dotazu prostřednictvím 527597 100 skutečných odhadů – takže pevný odhad je výrazně nerovnoměrný.
• U operace Vnořené smyčky se předpokládá, že se na vnější straně spojení vrátí pouze 100 řádků. Vzhledem k vysokému počtu řádků, které MSTVF skutečně vrací, bylo by pravděpodobně lepší použít zcela jiný spojovací algoritmus.
• V případě operace Shoda hodnot hash si všimněte malého symbolu upozornění, který v tomto případě označuje přelití na disk.

Porovnejte předchozí plán se skutečným plánem vygenerovaným s povoleným prokládáním provádění:

• Skenování tabulky MSTVF teď odráží přesný odhad kardinality. Všimněte si také změny pořadí prohledávání této tabulky a dalších operací.
• A pokud jde o algoritmy spojení, přešli jsme z operace vnořené smyčky na operaci porovnání hodnot hash, což je optimální vzhledem k velkému počtu zahrnutých řádků.
• Všimněte si také, že už nemáme upozornění na přelití, protože udělujeme více paměti na základě skutečného počtu řádků, který proudí z prohledávání tabulky MSTVF.

Příkazy způsobilé pro prokládané provádění

MsTVF odkazující příkazy při prokládaném provádění musí být v současné době jen pro čtení a nesmí být součástí operace úpravy dat. MSTVFs navíc nejsou způsobilé pro prokládané provádění, pokud nepoužívají konstanty za běhu.

Výhody prokládaného provádění

Obecně platí, že čím vyšší je nerovnoměrná distribuce mezi odhadovaným a skutečným počtem řádků ve spojení s počtem operací podřízeného plánu, tím větší je dopad na výkon.

Obecně platí, že prokládané vykonávání přináší výhody dotazům, kde:

• Mezi odhadovaným a skutečným počtem řádků pro zprostředkující sadu výsledků (v tomto případě MSTVF) je velká nerovnoměrná distribuce.

• A celkový dotaz je citlivý na změnu velikosti zprostředkujícího výsledku. K tomu obvykle dochází v případě, že je nad tímto podstromem v plánu dotazu komplexní strom.

  Základní SELECT * z MSTVF nemá výhodu z prokládaného provádění.

Režie při prokládaném provádění

Režijní náklady by měly být minimální až žádné. MSTVFs byly již materializovány před zavedením prokládaného provedení, ale rozdíl je v tom, že nyní povolujeme odloženou optimalizaci a pak používáme odhad kardinality materializované sady řádků. Stejně jako u jakéhokoli plánu, který má vliv na změny, by se některé plány mohly změnit tak, aby s lepší kardinalitou pro podstrom získaly horší plán pro dotaz celkově. Zmírnění může zahrnovat vrácení úrovně kompatibility nebo použití úložiště dotazů k vynucení verze plánu bez regrese.

Prokládané provádění a po sobě jdoucí provedení

Jakmile se prokládaný plán provádění uloží do mezipaměti, plán s revidovanými odhady prvního spuštění se použije pro následující spuštění bez opětovného vytvoření prokládaného provádění.

Sledování aktivity zamíchaného zpracování

Atributy využití můžete zobrazit ve skutečném plánu provádění dotazů:

Atribut Plán provádění	Description
ContainsInterleavedExecutionCandidates	Platí pro uzel QueryPlan . Pokud je pravda, znamená to, že plán obsahuje prokládané kandidáty na provádění.
IsInterleavedExecuted	Atribut elementu RuntimeInformation v rámci RelOp pro uzel TVF. Pokud je pravda, znamená to, že operace byla materializována jako součást současně prováděné operace.

Můžete také sledovat výskyty provádění prokládání prostřednictvím následujících rozšířených událostí:

XEvent	Description
interleaved_exec_status	Tato událost se aktivuje při prokládání provádění.
interleaved_exec_stats_update	Tato událost popisuje odhady kardinality aktualizované prokládáním provádění.
Interleaved_exec_disabled_reason	Tato událost se vyvolá, když dotaz s potenciálním kandidátem na prokládané spuštění ve skutečnosti nedosáhne prokládaného spuštění.

Dotaz musí být proveden, aby bylo možné umožnit prokládání provádění a revidovat odhady kardinality MSTVF. Odhadovaný plán provádění se ale stále zobrazuje, když jsou kandidáti pro prokládané provádění prostřednictvím showplan atributu ContainsInterleavedExecutionCandidates.

Ukládání do mezipaměti při prokládaném vykonávání

Pokud je plán vymazán nebo odstraněn z mezipaměti, při spuštění dotazu dojde k nové kompilaci, která využívá prokládané provádění. Příkaz using OPTION (RECOMPILE) vytvoří nový plán pomocí prokládaného zpracování a neuloží ho do mezipaměti.

Interoperabilita paralelního spouštění a úložiště dotazů

Plány využívající prokládané vykonávání je možné vynutit. Plán je verze, která obsahuje opravené odhady kardinality na základě počátečního spuštění.

Zakázat prokládané provádění beze změny úrovně kompatibility

Prokládání spouštění je možné zakázat v oboru databáze nebo příkazu a přitom zachovat úroveň kompatibility databáze 140 a vyšší. Chcete-li zakázat prokládáné provádění všech spuštěných dotazů pocházejících z databáze, spusťte v kontextu příslušné databáze následující příkaz:

-- SQL Server 2017
ALTER DATABASE SCOPED CONFIGURATION SET DISABLE_INTERLEAVED_EXECUTION_TVF = ON;

-- Starting with SQL Server 2019, and in Azure SQL Database
ALTER DATABASE SCOPED CONFIGURATION SET INTERLEAVED_EXECUTION_TVF = OFF;

Pokud je toto nastavení povolené, zobrazí se v sys.database_scoped_configurations jako povolené. Chcete-li znovu povolit prokládané provádění pro všechny dotazy pocházející z databáze, spusťte v kontextu příslušné databáze následující příkaz:

-- SQL Server 2017
ALTER DATABASE SCOPED CONFIGURATION SET DISABLE_INTERLEAVED_EXECUTION_TVF = OFF;

-- Starting with SQL Server 2019, and in Azure SQL Database
ALTER DATABASE SCOPED CONFIGURATION SET INTERLEAVED_EXECUTION_TVF = ON;

Můžete také zakázat prokládání provádění konkrétního dotazu tak, že se označí DISABLE_INTERLEAVED_EXECUTION_TVF jako nápověda k dotazu USE HINT. Například:

SELECT [fo].[Order Key],
       [fo].[Quantity],
       [fol].[OutlierEventQuantity]
FROM [Fact].[Order] AS [fo]
     INNER JOIN [Fact].[WhatIfOutlierEventQuantity]('Mild Recession', '1-01-2013', '10-15-2014') AS [fol]
         ON [fo].[Order Key] = [fol].[Order Key]
        AND [fo].[City Key] = [fol].[City Key]
        AND [fo].[Customer Key] = [fol].[Customer Key]
        AND [fo].[Stock Item Key] = [fol].[Stock Item Key]
        AND [fo].[Order Date Key] = [fol].[Order Date Key]
        AND [fo].[Picked Date Key] = [fol].[Picked Date Key]
        AND [fo].[Salesperson Key] = [fol].[Salesperson Key]
        AND [fo].[Picker Key] = [fol].[Picker Key]
OPTION (USE HINT('DISABLE_INTERLEAVED_EXECUTION_TVF'));

Tip dotazu USE HINT má přednost před nastavením příznaku trasování nebo konfigurací v oboru databáze.

Vložení skalárních uživatelsky definovaných funkcí

Platí pro: SQL Server (počínaje SQL Serverem 2019 (15.x)), Azure SQL Database

Skalární vkládání uživatelsky definovaných funkcí automaticky transformuje skalární uživatelsky definované funkce (UDF) do relačních výrazů. Vloží je do volajícího dotazu SQL. Tato transformace zlepšuje výkon úloh, které využívají skalární UDF (uživatelsky definované funkce). Vkládání skalárních UDF usnadňuje optimalizaci operací na základě nákladů uvnitř UDF. Výsledky jsou efektivní, orientované na sady a paralelní, na rozdíl od neefektivních, iterativních, sériových plánů provádění. Tato funkce je ve výchozím nastavení povolená na úrovni kompatibility databáze 150 nebo vyšší.

Další informace najdete v tématu Innerování skalárních uživatelsky definovaných funkcí.

Odložená kompilace proměnné tabulky

Platí pro: SQL Server (počínaje SQL Serverem 2019 (15.x)), Azure SQL Database

Odložená kompilace proměnné tabulky zlepšuje kvalitu plánu a celkový výkon dotazů odkazujících na proměnné tabulky. Během optimalizace a počáteční kompilace plánu tato funkce šíří odhady kardinality založené na skutečných počtech řádků proměnných tabulky. Tyto přesné informace o počtu řádků se pak používají k optimalizaci operací podřízeného plánu.

Při odložené kompilaci proměnné tabulky se kompilace příkazu, který odkazuje na proměnnou tabulky, odloží až do prvního skutečného spuštění příkazu. Toto odložené chování kompilace je stejné jako chování dočasných tabulek. Výsledkem této změny je použití skutečné kardinality místo původního odhadu o jednom řádku.

Pokud chcete povolit odloženou kompilaci proměnných tabulky, povolte úroveň kompatibility databáze 150 nebo vyšší pro databázi, ke které jste připojení při spuštění dotazu.

Odložená kompilace proměnné tabulky nemění žádné další vlastnosti proměnných tabulky. Tato funkce například nepřidává statistiky sloupců do proměnných tabulky.

Odložená kompilace proměnné tabulky nezvyšuje frekvenci rekompilace. Místo toho se posune tam, kde probíhá počáteční kompilace. Výsledný plán uložený v mezipaměti se generuje na základě počátečního počtu řádků proměnných tabulky odložené kompilace. Plán uložený v mezipaměti se opakovaně používá po sobě jdoucími dotazy. Používá se opakovaně, dokud se plán nevyřadí nebo znovu nekompiluje.

Počet řádků proměnných tabulky, který se používá pro počáteční kompilaci plánu, představuje typickou hodnotu, která se může lišit od odhadu počtu pevných řádků. Pokud se liší, podřízené operace z toho těží. Výkon nemusí být touto funkcí vylepšen, pokud se počet řádků proměnných tabulky výrazně liší v rámci provádění.

Zakázání odložené kompilace proměnné tabulky beze změny úrovně kompatibility

Zakažte odloženou kompilaci tabulkové proměnné v oboru databáze nebo příkazu, zatímco se zachovává úroveň kompatibility databáze 150 a vyšší. Chcete-li zakázat odloženou kompilaci proměnné tabulky pro všechna spuštění dotazů pocházející z databáze, spusťte následující příklad v kontextu příslušné databáze:

ALTER DATABASE SCOPED CONFIGURATION SET DEFERRED_COMPILATION_TV = OFF;

Pokud chcete znovu povolit odloženou kompilaci proměnné tabulky pro všechna spuštění dotazů pocházející z databáze, spusťte následující příklad v kontextu příslušné databáze:

ALTER DATABASE SCOPED CONFIGURATION SET DEFERRED_COMPILATION_TV = ON;

Zakázání odložené kompilace proměnných tabulky pro konkrétní dotaz můžete také provést přiřazením DISABLE_DEFERRED_COMPILATION_TV jako USE HINT query hint. Například:

DECLARE @LINEITEMS TABLE (
    L_OrderKey INT NOT NULL,
    L_Quantity INT NOT NULL);

INSERT @LINEITEMS
SELECT L_OrderKey,
       L_Quantity
FROM dbo.lineitem
WHERE L_Quantity = 5;

SELECT O_OrderKey,
       O_CustKey,
       O_OrderStatus,
       L_QUANTITY
FROM ORDERS, @LINEITEMS
WHERE O_ORDERKEY = L_ORDERKEY
      AND O_OrderStatus = 'O'
OPTION (USE HINT('DISABLE_DEFERRED_COMPILATION_TV'));

Optimalizace plánu citlivosti parametrů

Platí pro: SQL Server 2022 (16.x) a novější verze Azure SQL DatabaseAzure SQL Managed Instance

Optimalizace plánu citlivosti parametru (PSP) je součástí řady funkcí inteligentního zpracování dotazů. Řeší scénář, kdy jeden plán uložený v mezipaměti parametrizovaného dotazu není optimální pro všechny možné příchozí hodnoty parametrů. Jedná se o případ s neuniformní distribucí dat.

• Další informace o optimalizaci PSP naleznete v tématu Optimalizace plánu závislého na parametrech.
• Další informace o parametrizaci a citlivosti parametrů najdete v tématu Citlivost parametrů a Parametry a Opětovné použití plánu spuštění.

Přibližné zpracování dotazů

Přibližné zpracování dotazů je nová řada funkcí. Agreguje se napříč velkými datovými sadami, kde je odezva důležitější než absolutní přesnost. Příkladem je výpočet COUNT(DISTINCT()) napříč 10 miliardami řádků pro zobrazení na řídicím panelu. V tomto případě není absolutní přesnost důležitá, ale rychlost odezvy je kritická.

Přibližný počet jedinečných

Platí pro: SQL Server (počínaje SQL Serverem 2019 (15.x)), Azure SQL Database

Nová agregační funkce APPROX_COUNT_DISTINCT vrátí přibližný počet jedinečných hodnot, které nejsou null ve skupině.

Tato funkce je dostupná od SQL Serveru 2019 (15.x) bez ohledu na úroveň kompatibility.

Další informace najdete v tématu APPROX_COUNT_DISTINCT.

Přibližný percentil

platí pro: SQL Server (počínaje SQL Serverem 2022 (16.x)), Azure SQL Database

Tyto agregační funkce vypočítají percentily pro velkou datovou sadu s přijatelnými hranicemi chyb založených na pořadí, které pomáhají rychle rozhodovat pomocí přibližných agregačních funkcí percentilu.

Další informace najdete v tématu APPROX_PERCENTILE_DISC a APPROX_PERCENTILE_CONT

Režim Batch v úložišti řádků

Platí pro: SQL Server (počínaje SQL Serverem 2019 (15.x)), Azure SQL Database

Režim Batch v úložišti řádků umožňuje spouštění dávkového režimu pro analytické úlohy bez nutnosti indexů columnstore. Tato funkce podporuje provádění dávkového režimu a bitmapové filtry pro haldy na disku a indexy B-tree. Režim dávkového zpracování v úložišti řádkového formátu povoluje podporu pro všechny existující operátory s povoleným režimem dávkového zpracování.

Note

Dokumentace používá termín B-tree obecně v odkazu na indexy. V indexech rowstore databázový stroj implementuje strom B+. To neplatí pro indexy columnstore ani indexy v tabulkách optimalizovaných pro paměť. Další informace najdete v SQL Serveru a architektuře indexu Azure SQL a průvodci návrhem.

Přehled spouštění dávkového režimu

SQL Server 2012 (11.x) zavedl novou funkci pro zrychlení analytických úloh: indexy columnstore. Případy použití a výkon indexů columnstore se v každé další verzi SQL Serveru zvýšily. Vytváření indexů columnstore v tabulkách může zvýšit výkon analytických úloh. Existují však dvě související, ale odlišné sady technologií:

• U indexů columnstore přistupují analytické dotazy pouze k datům ve sloupcích, které potřebují. Komprese stránky ve formátu columnstore je také efektivnější než komprese v tradičních indexech rowstore .
• Při dávkovém zpracování zpracovávají operátory dotazů data efektivněji. Zpracovávají dávku řádků místo jednoho řádku najednou. Řada dalších vylepšení škálovatelnosti je svázaná se zpracováním dávkového režimu. Další informace o dávkovém režimu naleznete v tématu Režimy spuštění.

Dvě sady funkcí spolupracují na vylepšení vstupu a výstupu (vstupně-výstupních operací) a využití procesoru:

• Pomocí indexů columnstore se více dat vejde do paměti. Tím se sníží zatížení vstupně-výstupních operací.
• Dávkové zpracování využívá procesor efektivněji.

Obě technologie se vzájemně využívají, kdykoli je to možné. Agregace v dávkovém režimu lze například vyhodnotit jako součást prohledávání columnstore indexu. Také komprimovaná data columnstore jsou zpracovávána mnohem efektivněji pomocí kódování délek řetězců ve spojení a agregaci v dávkovém režimu.

Je ale důležité pochopit, že tyto dvě funkce jsou nezávislé:

• Můžete získat plány v režimu řádků, které používají sloupcové indexy.
• Můžete získat plány dávkového režimu, které používají pouze indexy typu rowstore.

Nejlepších výsledků obvykle dosáhnete, když tyto dvě funkce použijete společně. Před SQL Serverem 2019 (15.x) optimalizátor dotazů SQL Serveru zvažoval dávkový režim zpracování pouze pro dotazy, které zahrnují alespoň jednu tabulku s indexem columnstore.

Indexy columnstore nemusí být vhodné pro některé aplikace. Aplikace může použít jinou funkci, která není podporována u indexů columnstore. Místní úpravy například nejsou kompatibilní s kompresí columnstore. Triggery se proto nepodporují u tabulek s clusterovanými indexy columnstore. Důležitější je, že indexy columnstore přidávají režijní náklady na příkazy DELETE a UPDATE .

U některých hybridních transakčních analytických úloh převáží režie transakční úlohy nad výhodami získanými z používání indexů columnstore. Tyto scénáře můžou těžit z vylepšeného využití procesoru použitím výhradně dávkového zpracování. To je důvod, proč funkce "batch-mode-on-rowstore" zvažuje dávkový režim pro všechny dotazy bez ohledu na typ použitých indexů.

Úlohy, které můžou využívat dávkový režim v řádkovém úložišti.

Z dávkového režimu v úložišti řádků můžou těžit následující úlohy:

• Významná část úlohy se skládá z analytických dotazů. Tyto dotazy obvykle používají operátory, jako jsou spojení nebo agregace, které zpracovávají stovky tisíc řádků nebo více.
• Úloha je vázána na procesor. Pokud je kritickým bodem I/O, je doporučeno zvážit index columnstore, pokud je to možné.
• Vytvoření indexu columnstore přidává příliš velkou režii k transakční části vašeho pracovního vytížení. Nebo vytvoření indexu columnstore není možné, protože vaše aplikace závisí na funkci, která ještě není u indexů columnstore podporovaná.

Note

Dávkový režim v rowstore pomáhá pouze tím, že snižuje spotřebu procesoru. Pokud je kritickým bodem vstupně-výstupní operace a data nejsou již v mezipaměti (studená mezipaměť), dávkový režim na rowstore nezlepší dobu trvání dotazu. Podobně platí, že pokud na počítači není dostatek paměti pro ukládání všech dat do mezipaměti, je nepravděpodobné zlepšení výkonu.

Jaké změny nastávají v dávkovém režimu v úložišti řádků?

Režim dávkového zpracování v úložišti řádků vyžaduje, aby databáze byla na úrovni kompatibility 150.

I když dotaz nemá přístup k žádným tabulkám s indexy columnstore, procesor dotazů používá heuristiku k rozhodnutí, jestli se má zvážit dávkový režim. Heuristiky se skládají z těchto kontrol:

1. Počáteční kontrola velikostí tabulek, použitých operátorů a odhadovaných kardinalit ve vstupním dotazu.
2. Další kontrolní body, protože optimalizátor zjistí nové a levnější plány pro dotaz. Pokud tyto alternativní plány nevyužívají dávkový režim, optimalizátor přestane zkoumat alternativy dávkového režimu.

Pokud je v úložišti řádků použit režim dávkového zpracování, uvidíte v plánu dotazu jako skutečný režim spuštění režim dávkového zpracování. Operátor skenování používá dávkový režim pro haldy na disku a indexy B-tree. Tato dávková kontrola může vyhodnotit rastrové filtry v dávkovém režimu. V plánu se také mohou zobrazit další operátory dávkového režimu. Příkladem jsou hash spojení, agregace založené na hash, řazení, okenní agregace, filtry, zřetězení a skalární operátory při výpočtu.

Remarks

Plány dotazů vždy nepoužívají dávkový režim. Optimalizátor dotazů se může rozhodnout, že pro dotaz není prospěšný dávkový režim.

Vyhledávací prostor Optimalizátoru dotazů se mění. Pokud tedy získáte plán režimu řádků, nemusí být stejný jako plán, který získáte na nižší úrovni kompatibility. A pokud získáte plán pro dávkový režim, nemusí být stejný jako plán, který získáte se sloupcovým indexem.

Plány se také můžou změnit u dotazů, které kombinují indexy columnstore a rowstore kvůli novému skenování rowstore v batch módu.

V novém dávkovém režimu při prohledávání rowstore existují aktuální omezení:

• Nebude fungovat pro OLTP tabulky v paměti ani pro jiné indexy než uložené haldy na disku a B-stromy.
• Také se neaktivuje, pokud se načte nebo filtruje sloupec velkého objektu (LOB). Toto omezení zahrnuje řídké sady sloupců a sloupce XML.

Existují dotazy, pro které se dávkový režim nepoužívá ani u indexů columnstore. Příklady jsou dotazy, které zahrnují kurzory. Tato stejná vyloučení se také vztahují na dávkový režim v řádkovém úložišti.

Konfigurujte dávkový režim na úložišti řádků

Konfigurace BATCH_MODE_ON_ROWSTOREs vymezeným oborem databáze je ve výchozím nastavení zapnutá.

Můžete vypnout režim dávkového zpracování v úložišti řádků bez změny úrovně kompatibility databáze.

-- Disabling batch mode on rowstore
ALTER DATABASE SCOPED CONFIGURATION SET BATCH_MODE_ON_ROWSTORE = OFF;

-- Enabling batch mode on rowstore
ALTER DATABASE SCOPED CONFIGURATION SET BATCH_MODE_ON_ROWSTORE = ON;

Dávkový režim v úložišti řádků můžete zakázat prostřednictvím konfigurace databáze s vymezeným oborem. Nastavení ale můžete na úrovni dotazu přepsat pomocí klíčového slova ALLOW_BATCH_MODE v dotazu. Následující příklad umožňuje dávkový režim v úložišti řádků, i když je funkce zakázána pomocí konfigurace databáze s vymezeným oborem.

SELECT [Tax Rate],
       [Lineage Key],
       [Salesperson Key],
       SUM(Quantity) AS SUM_QTY,
       SUM([Unit Price]) AS SUM_BASE_PRICE,
       COUNT(*) AS COUNT_ORDER
FROM Fact.OrderHistoryExtended
WHERE [Order Date Key] <= DATEADD(dd, -73, '2015-11-13')
GROUP BY [Tax Rate], [Lineage Key], [Salesperson Key]
ORDER BY [Tax Rate], [Lineage Key], [Salesperson Key]
OPTION (RECOMPILE, USE HINT('ALLOW_BATCH_MODE'));

Dávkový režim zpracování můžete také zakázat v úložišti řádků pro konkrétní dotaz pomocí nápovědy k dotazu DISALLOW_BATCH_MODE. Podívejte se na následující příklad:

SELECT [Tax Rate],
       [Lineage Key],
       [Salesperson Key],
       SUM(Quantity) AS SUM_QTY,
       SUM([Unit Price]) AS SUM_BASE_PRICE,
       COUNT(*) AS COUNT_ORDER
FROM Fact.OrderHistoryExtended
WHERE [Order Date Key] <= DATEADD(dd, -73, '2015-11-13')
GROUP BY [Tax Rate], [Lineage Key], [Salesperson Key]
ORDER BY [Tax Rate], [Lineage Key], [Salesperson Key]
OPTION (RECOMPILE, USE HINT('DISALLOW_BATCH_MODE'));

Funkce zpětné vazby pro zpracování dotazů

Funkce zpětné vazby pro zpracování dotazů jsou součástí řady funkcí inteligentního zpracování dotazů.

Zpětná vazba ke zpracování dotazů je proces, pomocí kterého procesor dotazů v SQL Serveru, Azure SQL Database a Azure SQL Managed Instance používá historická data o provádění dotazu, aby se rozhodlo, jestli dotaz může získat pomoc od jedné nebo více změn způsobu kompilace a spuštění dotazu. Data o výkonu se shromažďují v úložišti dotazů s různými návrhy ke zlepšení provádění dotazů. V případě úspěchu tyto úpravy disku uchováváme v paměti nebo v úložišti dotazů pro budoucí použití. Pokud návrhy nepřinesou dostatečné zlepšení, zahodí se a dotaz se bude dál spouštět bez této zpětné vazby.

Informace o tom, které funkce zpětné vazby pro zpracování dotazů jsou k dispozici v různých verzích SQL Serveru nebo ve službě Azure SQL Database nebo ve službě Azure SQL Managed Instance, najdete v tématu Inteligentní zpracování dotazů v databázích SQL nebo v následujících článcích pro každou funkci zpětné vazby.

Zpětná vazba k přidělení paměti

Zpětná vazba na přidělování paměti byla zavedena ve vlnách v minulých hlavních verzích SQL Serveru.

Zpětná vazba pro přidělení paměti v dávkovém režimu

Informace o zpětné vazbě k udělení paměti v režimu Batch najdete v tématu Váš názor na udělení paměti v režimu Batch.

Zpětná vazba k udělení paměti v režimu řádků

Pro informace o zpětné vazbě při přidělení paměti v režimu řádků, navštivte zpětná vazba při přidělení paměti v režimu řádků.

Zpětná vazba na paměťové přidělení v režimu percentilu a perzistence

Informace o zpětné vazbě na udělení paměti v režimech percentilu a trvalosti najdete v Percentile a režim trvalosti zpětné vazby udělení paměti.

Stupeň paralelismu (DOP) – zpětná vazba

Informace o zpětné vazbě DOP najdete v tématu Stupeň paralelismu (DOP).

Odhad kardinality (CE) - zpětná vazba

Informace o zpětné vazbě CE najdete v názorech odhadu kardinality (CE).

Vynucení optimalizovaného plánu pomocí úložiště dotazů

Informace o optimalizovaném vynucování plánů pomocí úložiště dotazů najdete na Optimalizované vynucování plánů pomocí úložiště dotazů.

Související obsah

• spojení (SQL Server)
• Režimy provádění
• Průvodce architekturou zpracování dotazů
• Odkaz na operátory logického a fyzického plánu zobrazení
• ÚPRAVA KONFIGURACE S ROZSAHEM DATABÁZE (Transact-SQL)
• Novinky v SQL Serveru 2017
• Novinky v SQL Serveru 2019
• Novinky v SQL Serveru 2022
• demonstrování inteligentního zpracování dotazů
• Konstantní posouvání a vyhodnocení výrazů
• Ukázky inteligentního zpracování dotazů na GitHubu
• Performance Center pro databázový stroj SQL Serveru a službu Azure SQL Database
• Monitorování výkonu s využitím úložiště dotazů
• osvědčené postupy pro monitorování úloh pomocí úložiště dotazů