Dela via

Intelligenta frågebearbetningsfunktioner i detalj

Gäller för:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceSQL-databas i Microsoft Fabric

Den här artikeln innehåller djupgående beskrivningar av olika funktioner för intelligent frågebearbetning (IQP), viktig information och mer information. Funktionsfamiljen intelligent frågebearbetning (IQP) innehåller funktioner med bred inverkan som förbättrar prestandan för befintliga arbetsbelastningar med minimal implementering.

Du kan göra arbetsbelastningar automatiskt berättigade till intelligent frågebearbetning genom att aktivera den tillämpliga databaskompatibilitetsnivån för databasen. Du kan ange detta med Transact-SQL. Om du till exempel vill ange en databass kompatibilitetsnivå till SQL Server 2022 (16.x):

ALTER DATABASE [WideWorldImportersDW] SET COMPATIBILITY_LEVEL = 160;

Mer information om ändringar som introduceras med nya versioner finns i:

Anpassningsbara kopplingar i Batch-läge

Gäller för: SQL Server (från och med SQL Server 2017 (14.x)), Azure SQL Database

Funktionen Adaptive Joins i batchläge gör att valet av en Hash Join- eller Nested Loops Join-metod kan skjutas upp tills efter att den första indatan har genomsökts med hjälp av en enda cachelagrad plan. Operatorn Adaptive Join definierar ett tröskelvärde som används för att bestämma när en kapslad loopplan ska växlas. Din plan kan därför dynamiskt växla till en bättre kopplingsstrategi under körningen.

Mer information, inklusive hur du inaktiverar adaptiva kopplingar utan att ändra kompatibilitetsnivån, finns i Förstå adaptiva kopplingar.

Interleaved-körning för MSTVFs

Gäller för: SQL Server (från och med SQL Server 2017 (14.x)), Azure SQL Database

En tabellvärdesfunktion med flera instruktioner (MSTVF) är en typ av användardefinierad funktion som kan acceptera parametrar, köra flera T-SQL-instruktioner och RETURN en tabell.

Interfolierad körning hjälper arbetsbelastningens prestandaproblem som beror på fasta kardinalitetsuppskattningar som är associerade med MSTVF:er. Med interfolierad körning används de faktiska radantalen från funktionen för att bättre informera om följande frågeplanbeslut.

MSTVFs har en fast kardinalitets gissning på 100 från och med SQL Server 2014 (12.x) och 1 för tidigare SQL Server-versioner.

Interfolierad körning ändrar den enkelriktade gränsen mellan optimerings- och körningsfaserna för en körning med en enda fråga och gör det möjligt för planer att anpassa sig baserat på de reviderade kardinalitetsuppskattningarna. Under optimeringen, om databasmotorn stöter på en kandidat för interfolierad exekvering som använder tabellvärdesfunktioner med flera satser (MSTVFs), pausar optimeringen, kör tillämpligt underträd, samlar in korrekta kardinalitetsuppskattningar och återupptar sedan optimeringen för åtgärder nedströms.

Följande bild visar livefrågestatistikens utdata , en delmängd av en övergripande körningsplan som visar effekten av uppskattningar av fast kardinalitet från MSTVF:er

Du kan se det faktiska radflödet jämfört med uppskattade rader. Det finns tre anmärkningsvärda områden i planen (flödet är från höger till vänster):

  • MSTVF-tabellgenomsökningen har en fast uppskattning på 100 rader. I det här exemplet finns det dock 527 597 rader som flödar genom den här MSTVF-tabellskanningen, som visas i Live Query Statistics med 527597 av 100 faktiska av uppskattade - så den fasta uppskattningen är betydligt skev.
  • För åtgärden Kapslade loopar antas endast 100 rader returneras av den yttre sidan av kopplingen. Med tanke på det stora antalet rader som faktiskt returneras av MSTVF är det troligt att du har det bättre med en helt annan kopplingsalgoritm.
  • Observera den lilla varningssymbolen för Hash Match-åtgärden, som i det här fallet indikerar ett spill till disken.

Bild av ett körningsplans radflöde jämfört med uppskattade rader.

Jämför den tidigare planen med den faktiska planen som genererades med sammankopplad körning aktiverad.

Bild av Interleaved-körningsplan.

  • Observera att MSTVF-tabellgenomsökningen nu återspeglar en korrekt kardinalitetsuppskattning. Observera även omordningen av den här tabellgenomsökningen och de andra åtgärderna.
  • Och när det gäller kopplingsalgoritmer har vi växlat från en kapslad loopåtgärd till en Hash Match-åtgärd i stället, vilket är mer optimalt med tanke på det stora antalet rader som ingår.
  • Observera också att vi inte längre har spillvarningar eftersom vi tilldelar mer minne baserat på det verkliga antalet rader som flödar ut från tabellgenomsökningen av MSTVF.

Godkända instruktioner i samband med samtidig körning

MSTVF-referensuttryck i sammanvävd körning måste vara läsbara och inte en del av en dataändringsoperation. MSTVFs är inte heller berättigade till växelvis körning om de inte använder körningskonstanter.

Fördelar med växelvis exekvering

I allmänhet, ju högre skevhet mellan det uppskattade jämfört med det faktiska antalet rader, i kombination med antalet underordnade planåtgärder, desto större prestandapåverkan.

I allmänhet är frågor om interleaved körningsfördelar där:

  • Det finns en stor skevhet mellan det uppskattade jämfört med det faktiska antalet rader för den mellanliggande resultatuppsättningen (i det här fallet MSTVF).
  • Och den övergripande frågan är känslig för en ändring i storleken på det mellanliggande resultatet. Detta inträffar vanligtvis när det finns ett komplext träd ovanför underträdet i frågeplanen. En enkel SELECT * från en MSTVF kommer inte att dra nytta av interfolierad utförande.

Kostnad för växlad exekvering

Omkostnaderna bör vara minimala till inga. MSTVFs materialiserades redan innan interfolierad körning infördes, men skillnaden är att vi nu tillåter uppskjuten optimering och sedan använder kardinalitetsuppskattningen för den materialiserade raduppsättningen. Precis som med alla planer som påverkar ändringar kan vissa planer ändras så att vi med bättre kardinalitet för underträdet får en sämre plan för frågan överlag. Du kan till exempel återställa kompatibilitetsnivån eller använda Query Store för att tvinga fram den icke-regresserade versionen av planen.

Sammanflätad körning och sekventiella körningar

När en interfolierad körningsplan har cachelagrats används planen med de reviderade uppskattningarna för den första körningen för efterföljande körningar utan att underbygga interfolierad körning.

Spåra interfolierad körningsaktivitet

Du kan se användningsattribut i den faktiska frågekörningsplanen:

Körningsplanattribut Beskrivning
InnehållerVäxlandeKörningsKandidater Gäller för noden QueryPlan . När det är sant innebär det att planen innehåller mellanlagrade körningskandidater.
ÄrFlätatUtfört Attributet för elementet RuntimeInformation under RelOp för TVF-noden. När det är sant innebär det att åtgärden materialiserades som en del av en interfolierad körningsåtgärd.

Du kan också spåra förekomster av sammanflätad exekvering via följande utökade händelser:

XEvent Beskrivning
interleaved_exec_status Den här händelsen utlöses när parallell körning inträffar.
interleaved_exec_stats_update Den här händelsen beskriver kardinalitetsuppskattningarna som uppdateras av sammanflätad exekvering.
Interleaved_exec_disabled_reason Den här händelsen utlöses när en fråga med en möjlig kandidat för interfolierad körning faktiskt inte får interfolierad körning.

En fråga måste köras för att tillåta interfolierad körning för att ändra msTVF-kardinalitetsuppskattningar. Den uppskattade körningsplanen visar dock fortfarande när det finns sammanflätade körningskandidater via ContainsInterleavedExecutionCandidates showplan-attributet.

Sammanflätad körningscachelagring

Om en plan rensas eller tas bort från cacheminnet, sker det vid frågekörning en ny kompilering som använder sammanvävd exekvering. En instruktion som använder OPTION (RECOMPILE) skapar en ny plan med interfolierad körning och inte cachelagrar den.

Interleaved-körning och Query Store-samverkan

Planer som använder interlacerad körning kan tvingas fram. Planen är den version som har korrigerat kardinalitetsuppskattningar baserat på den första körningen.

Inaktivera parallell körning utan att ändra kompatibilitetsnivån

Interleaved-körning kan inaktiveras i databasen eller instruktionsomfånget samtidigt som databaskompatibilitetsnivån 140 och högre bibehålls. Om du vill inaktivera sammanflätad körning för alla frågekörningar som kommer från databasen, kör följande i kontexten av den aktuella databasen:

-- 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;

När den här inställningen är aktiverad visas den som aktiverad i sys.database_scoped_configurations. Om du vill återaktivera interfolierad körning för alla frågekörningar som utförs från databasen, kör du följande inom ramen för den aktuella databasen:

-- 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;

Du kan också inaktivera interfolierad körning för en specifik fråga genom att beteckna DISABLE_INTERLEAVED_EXECUTION_TVF som ett USE HINT-query hint. Till exempel:

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

En USE HINT-frågetips har företräde framför en inställning för databasomfattningskonfiguration eller spårningsflagga .

Skalär UDF-inlining

Gäller för: SQL Server (från och med SQL Server 2019 (15.x)), Azure SQL Database

Skalär UDF-inlining omvandlar automatiskt skalära UDF:er till relationsuttryck. Den bäddar in dem i den anropande SQL-frågan. Den här omvandlingen förbättrar prestandan för arbetsbelastningar som drar nytta av skalära UDF:er. Skalbar UDF-inlining underlättar kostnadsbaserad optimering av åtgärder i UDF:er. Resultaten är effektiva, setorienterade och parallella i stället för ineffektiva, iterativa, seriella körningsplaner. Den här funktionen är aktiverad som standard under databaskompatibilitetsnivå 150 eller senare.

Mer information finns i Scalar UDF-inlining.

Uppskjuten kompilering av tabellvariabel

Gäller för: SQL Server (från och med SQL Server 2019 (15.x)), Azure SQL Database

Uppskjuten kompilering av tabellvariabler förbättrar planens kvalitet och övergripande prestanda för frågor som refererar till tabellvariabler. Under optimering och inledande plankompilering sprider den här funktionen kardinalitetsuppskattningar som baseras på faktiska antal rader för tabellvariabler. Den här exakta radantalsinformationen används sedan för att optimera nedströms planeringsoperationer.

Med uppskjuten kompilering av tabellvariabler skjuts kompileringen av en instruktion som refererar till en tabellvariabel upp till den första faktiska körningen av instruktionen. Det här uppskjutna kompileringsbeteendet är identiskt med beteendet för tillfälliga tabeller. Den här ändringen resulterar i användning av faktisk kardinalitet i stället för den ursprungliga gissningen på en rad.

Aktivera uppskjuten kompilering av tabellvariabel genom att aktivera databaskompatibilitetsnivå 150 eller högre för databasen som du är ansluten till när frågan körs.

Uppskjuten kompilering av tabellvariabler ändrar inte andra egenskaper för tabellvariabler. Den här funktionen lägger till exempel inte till kolumnstatistik i tabellvariabler.

Uppskjuten kompilering av tabellvariabel ökar inte omkompileringsfrekvensen. I stället flyttas den där den första kompileringen sker. Den resulterande cachelagrade planen genereras baserat på det inledande antalet rader i den uppskjutna kompileringstabellvariabeln. Den cachelagrade planen återanvänds av frågeförfrågningar i följd. Planen återanvänds tills den tas bort eller omkompileras.

Antal tabellvariabler som används för den inledande plankompileringen representerar ett typiskt värde som kan skilja sig från en fast gissning för antal rader. Om det är annorlunda kan efterföljande processer dra nytta av det. Prestanda kanske inte förbättras av den här funktionen om antalet tabellvariabler varierar avsevärt mellan körningar.

Inaktivera uppskjuten kompilering av tabellvariabel utan att ändra kompatibilitetsnivån

Inaktivera uppskjuten kompilering av tabellvariabeln i databas- eller instruktionsomfånget samtidigt som databaskompatibilitetsnivån 150 och högre bibehålls. Om du vill inaktivera uppskjuten kompilering av tabellvariabel för alla frågekörningar som kommer från databasen kör du följande exempel i kontexten för den tillämpliga databasen:

ALTER DATABASE SCOPED CONFIGURATION SET DEFERRED_COMPILATION_TV = OFF;

Om du vill återaktivera uppskjuten kompilering av tabellvariabeln för alla frågekörningar som kommer från databasen kör du följande exempel i kontexten för den tillämpliga databasen:

ALTER DATABASE SCOPED CONFIGURATION SET DEFERRED_COMPILATION_TV = ON;

Du kan också inaktivera uppskjuten kompilering av tabellvariabeln för en viss fråga genom att tilldela DISABLE_DEFERRED_COMPILATION_TV som en USE HINT-frågetips. Till exempel:

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'));

Optimering av parameterkänslighetsplan

gäller för: SQL Server 2022 (16.x) Azure SQL DatabaseAzure SQL Managed Instance

Psp-optimering (Parameter Sensitivity Plan) är en del av den intelligenta frågebearbetningsfamiljen med funktioner. Den hanterar scenariot där en enda cachelagrad plan för en parameteriserad fråga inte är optimal för alla möjliga inkommande parametervärden. Detta är fallet med icke-enhetliga datadistributioner.

Ungefärlig bearbetning av frågor

Ungefärlig frågebearbetning är en ny funktionsfamilj. Den aggregerar över stora datamängder där svarstiden är mer kritisk än absolut precision. Ett exempel är att beräkna ett COUNT(DISTINCT()) på 10 miljarder rader för att visas på en instrumentpanel. I det här fallet är absolut precision inte viktigt, men svarstiden är kritisk.

Ungefärligt antal olika

Gäller för: SQL Server (från och med SQL Server 2019 (15.x)), Azure SQL Database

Den nya APPROX_COUNT_DISTINCT mängdfunktionen returnerar det ungefärliga antalet unika värden som inte är null i en grupp.

Den här funktionen är tillgänglig från och med SQL Server 2019 (15.x), oavsett kompatibilitetsnivå.

Mer information finns i APPROX_COUNT_DISTINCT (Transact-SQL).

Ungefärlig percentil

gäller för: SQL Server (från och med SQL Server 2022 (16.x)), Azure SQL Database

Dessa aggregeringsfunktioner beräknar percentiler för en stor datamängd med godtagbara rangbaserade felgränsningar för att fatta snabba beslut med hjälp av ungefärliga percentilaggregatfunktioner.

Mer information finns i APPROX_PERCENTILE_DISC (Transact-SQL) och APPROX_PERCENTILE_CONT (Transact-SQL)

Batchläge i raddatalager

Gäller för: SQL Server (från och med SQL Server 2019 (15.x)), Azure SQL Database

Batchläge på radlagring möjliggör användning för analytiska arbetsbelastningar utan behov av kolumnlagringsindex. Den här funktionen stöder batchlägeskörning och bitmappsfilter för heaps på disk och B-trädindex. Batchläge på radlagret möjliggör stöd för alla befintliga batchläge-aktiverade operatorer.

Anmärkning

I dokumentationen används termen B-träd vanligtvis som referens till index. I radlagringsindex implementerar databasmotorn ett B+-träd. Detta gäller inte för kolumnlagringsindex eller index i minnesoptimerade tabeller. Mer information finns i arkitekturen och designguiden för SQL Server och Azure SQL-index.

Översikt över körning av batchläge

SQL Server 2012 (11.x) introducerade en ny funktion för att påskynda analytiska arbetsbelastningar: kolumnlagringsindex. Användningsfall och prestanda för kolumnlagringsindex ökade i varje efterföljande version av SQL Server. Att skapa kolumnlagringsindex i tabeller kan förbättra prestandan för analytiska arbetsbelastningar. Det finns dock två relaterade men distinkta uppsättningar av tekniker:

  • Med kolumnlagringsindex kommer analysfrågor endast åt data i de kolumner som de behöver. Sidkomprimering i columnstore-format är också effektivare än komprimering i traditionella radlagringsindex .
  • Med bearbetning av batchläge bearbetar frågeoperatorer data mer effektivt. De arbetar med ett parti rader i stället för en rad i taget. Många andra skalbarhetsförbättringar är knutna till bearbetning i batchläge. Mer information om batchläge finns i Körningslägen.

De två uppsättningarna funktioner fungerar tillsammans för att förbättra indata/utdata (I/O) och CPU-användning:

  • Genom att använda columnstore-index passar mer av dina data i minnet. Det minskar I/O-arbetsbelastningen.
  • Bearbetning i batchläge använder CPU mer effektivt.

De två teknikerna utnyttjar varandra när det är möjligt. Batchlägesaggregeringar kan till exempel utvärderas som en del av en kolumnlagringsindexgenomsökning. Även komprimerad kolumnlagringsdata bearbetas mycket mer effektivt med hjälp av run-length-avkodning, batchkopplingar och batchaggregat.

Det är dock viktigt att förstå att de två funktionerna är oberoende:

  • Du kan hämta planer för radläge som använder kolumnlagringsindex.
  • Du kan hämta batchlägesplaner som endast använder radlagringsindex.

Du får vanligtvis de bästa resultaten när du använder de två funktionerna tillsammans. Före SQL Server 2019 (15.x) övervägde SQL Server-frågeoptimeraren endast bearbetning i batchläge för frågor som omfattar minst en tabell med ett kolumnlagringsindex.

Kolumnlagringsindex kanske inte är lämpliga för vissa program. Ett program kan använda en annan funktion som inte stöds med kolumnlagringsindex. Ändringar på plats är till exempel inte kompatibla med kolumnlagringskomprimering. Därför stöds inte utlösare i tabeller med grupperade kolumnlagringsindex. Ännu viktigare är att kolumnlagringsindex lägger till omkostnader för DELETE- och UPDATE-instruktioner .

För vissa hybridtransaktionsanalysarbetsbelastningar uppväger omkostnaderna för en transaktionsarbetsbelastning fördelarna med att använda kolumnlagringsindex. Sådana scenarier kan dra nytta av förbättrad CPU-användning genom att enbart använda bearbetning i batchläge. Därför tar funktionen batch-mode-on-rowstore hänsyn till batchläge för alla frågor oavsett vilken typ av index som ingår.

Arbetsbelastningar som kan dra nytta av satsvis bearbetning på radlager

Följande arbetslaster kan dra nytta av batchläge i radradlagring:

  • En betydande del av arbetsbelastningen består av analysfrågor. Vanligtvis använder dessa frågor operatorer som kopplingar eller aggregeringar som bearbetar hundratusentals rader eller mer.
  • Arbetsbelastningen är CPU-bunden. Om flaskhalsen är I/O rekommenderar vi fortfarande att du överväger ett kolumnlagringsindex, där det är möjligt.
  • Om du skapar ett kolumnlagringsindex läggs för mycket omkostnader till transaktionsdelen av arbetsbelastningen. Eller så är det inte möjligt att skapa ett columnstore-index eftersom ditt program är beroende av en funktion som ännu inte stöds med columnstore-index.

Anmärkning

Batchläge på radlagring hjälper endast med att reducera CPU-användningen. Om flaskhalsen är I/O-relaterad och data inte redan är cachelagrad ("kall" cache), kommer batchläge på radlager inte att förbättra frågens exekveringstid. På samma sätt, om det inte finns tillräckligt med minne på datorn för att cachelagma alla data, är en prestandaförbättring osannolik.

Vad ändras med batchläge i radlagring?

Batchläge i radlager kräver att databasen har kompatibilitetsnivå 150.

Även om en fråga inte har åtkomst till några tabeller med kolumnlagringsindex använder frågeprocessorn heuristik för att avgöra om batchläget ska övervägas. Heuristiken består av följande kontroller:

  1. En första kontroll av tabellstorlekar, operatorer som används och uppskattade kardinaliteter i indatafrågan.
  2. Ytterligare kontrollpunkter, eftersom optimeraren upptäcker nya, billigare planer för frågan. Om dessa alternativa planer inte använder batchläget i någon större grad slutar optimeraren att utforska alternativ i batchläge.

Om batchläge på rowstore används visas det faktiska körläget som batchläge i frågeplanen. Genomsökningsoperatorn använder batchläge för heaps på disk och B-trädindex. Den här batchlägesgenomsökningen kan utvärdera bitmappsfilter i batchläge. Du kan också se andra batchlägesoperatorer i planen. Exempel är hashkopplingar, hash-baserade aggregeringar, sortering, fönsteraggregat, filter, sammanfogning och beräkningsskalaroperatorer.

Anmärkningar

Frågeplaner använder inte alltid batchläge. Frågeoptimeraren kan besluta att batchläget inte är fördelaktigt för frågan.

Sökutrymmet för Frågeoptimeraren ändras. Så om du får en plan i radläge kan det hända att den inte är samma som den plan du får vid en lägre kompatibilitetsnivå. Och om du får en batchlägesplan kanske det inte är samma som den plan du får med ett kolumnlagringsindex.

Planer kan också ändras för frågor som blandar columnstore- och rowstore-index på grund av den nya radlagringsgenomsökningen i batchläge.

Det finns aktuella begränsningar för det nya batchläget vid rowstore-genomsökning:

  • Den startar inte för minnesinterna OLTP-tabeller eller för andra index än på diskhögar och B-träd.
  • Den startar inte heller om en stor objektkolumn (LOB) hämtas eller filtreras. Den här begränsningen omfattar glesa kolumnuppsättningar och XML-kolumner.

Det finns frågor som batchläge inte används för även med columnstore-index. Exempel är frågor som omfattar markörer. Dessa undantag utökas också till batchläge i rowstore-lagring.

Konfigurera batchläge i rowstore

Databasens BATCH_MODE_ON_ROWSTOREbegränsade konfiguration är PÅ som standard.

Du kan inaktivera batchläge på radlagring utan att ändra databasens kompatibilitetsnivå:

-- 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;

Du kan inaktivera batchläge i radarkiv via databasomfattningskonfiguration. Men du kan fortfarande åsidosätta inställningen på frågenivå med hjälp av frågetipset ALLOW_BATCH_MODE . I följande exempel möjliggörs batchläge på radtabelldatabaser även om funktionen är inaktiverad via databasens omfattningskonfiguration.

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'));

Du kan också inaktivera batchläge i radarkivet för en specifik fråga med hjälp av frågetipset DISALLOW_BATCH_MODE . Se följande exempel:

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'));

Funktioner för feedback om frågebearbetning

Feedbackfunktionerna för frågebearbetning är en del av den intelligenta frågebearbetningsfamiljen med funktioner.

Feedback om frågebearbetning är en process där frågeprocessorn i SQL Server, Azure SQL Database och Azure SQL Managed Instance använder historiska data om en frågas körning för att avgöra om frågan kan få hjälp från en eller flera ändringar i hur den kompileras och körs. Prestandadata samlas in i Query Store, där olika förslag ges för att förbättra frågeexekveringen. Om det lyckas bevarar vi dessa ändringar av disken i minnet och/eller i Query Store för framtida användning. Om förslagen inte ger tillräcklig förbättring ignoreras de och frågan fortsätter att köras utan den feedbacken.

Information om vilka funktioner för frågebearbetning som är tillgängliga i olika versioner av SQL Server eller i Azure SQL Database eller Azure SQL Managed Instance finns i Intelligent frågebearbetning i SQL-databaser eller följande artiklar för varje feedbackfunktion.

Återkoppling om minnestilldelning

Feedback om minnesbidrag har introducerats i vågor under de senaste större versionerna av SQL Server.

Feedback om minnestilldelning i batch-läge

Information om minnesbeviljandefeedback i batchläge finns i feedback om minnesbeviljande i batchläge.

Feedback för minnesbeviljande i radläge

För information om minnesgranskningsfeedback i radläge, besök Minnesgranskningsfeedback i radläge.

Feedback om minnesbeviljande i percentil- och beständighetsläge

Information om feedback om minnestilldelning i percentil- och beständighetsläge finns i Feedback om minnestilldelning i percentil- och beständighetsläge.

Grad av parallellism (DOP) - återkoppling

Information om DOP-feedback finns i DoP-feedback (Grad av parallellitet).

Feedback om kardinalitetsuppskattning (CE)

Information om CE-feedback finns i Feedback om kardinalitetsuppskattning (CE).

Optimerad plan framtvingas med Query Store

Information om optimerad plan framtvingning med Query Store finns i Optimerad plan framtvingning med Query Store.

Optimerat Halloween-skydd

Gäller för: SQL Server (från och med SQL Server 2025 (17.x) Förhandsversion)

Optimerat Halloween-skydd kan minska tempdb utrymmesförbrukningen och förbättra frågeprestanda genom att designa om hur databasmotorn löser Halloween-problemet. Det här problemet uppstår när en DML-instruktion (Data Modification Language) ändrar data på ett sådant sätt att samma instruktion oväntat bearbetar en rad mer än en gång.

Traditionellt skyddar databasmotorn DML-instruktioner från Halloween-problemet genom att introducera en Spool-operator i frågeplanen eller genom att dra nytta av en annan blockeringsoperator som redan finns i planen, till exempel en sorterings- eller hashmatchning.

Om en Spool-operator används skapar den en tillfällig kopia av de data som ska ändras innan några ändringar görs i data i tabellen.

Även om skyddspoolen undviker Halloween-problemet har den nackdelar:

  • Spoolen kräver extra utrymme i tempdb, extra disk-I/O och CPU för att skriva och läsa data och extra minne för att cacha data.
  • Instruktionsbearbetning av underordnade frågeoperatorer blockeras tills data skrivs helt i bufferten.
  • Spoolen lägger till frågeplanskomplexitet som kan göra att frågeoptimeraren genererar en mindre optimal plan.

Optimerat Halloween-skydd tar bort dessa nackdelar genom att göra Spool-operatorn onödig.

Använda optimerat Halloween-skydd

För att aktivera optimerat Halloween-skydd för en databas krävs följande krav:

Konfigurationen OPTIMIZED_HALLOWEEN_PROTECTION med databasomfattning är aktiverad som standard. Det innebär att när du aktiverar ADR för en databas med kompatibilitetsnivå 170 börjar databasen använda optimerat Halloween-skydd.

Kör följande instruktioner för att säkerställa att en databas använder optimerat Halloween-skydd:

ALTER DATABASE [<database-name-placeholder>] SET ACCELERATED_DATABASE_RECOVERY = ON;
ALTER DATABASE [<database-name-placeholder>] SET COMPATIBILITY_LEVEL = 170;
ALTER DATABASE SCOPED CONFIGURATION SET OPTIMIZED_HALLOWEEN_PROTECTION = ON;

För att aktivera ADR krävs ett exklusivt lås på databasen. Det innebär att ALTER DATABASE ... SET ACCELERATED_DATABASE_RECOVERY = ON kommandot blockeras medan det finns andra sessioner i databasen och att alla nya sessioner väntar bakom dessa ALTER DATABASE kommandon. Om du vill aktivera ADR utan att vänta kan du lägga till avslutningssatsen WITH ROLLBACK IMMEDIATE i ALTER DATABASE kommandot för att avbryta alla aktiva sessioner i databasen.

Om du vill inaktivera optimerat Halloween-skydd för en databas inaktiverar du konfigurationen OPTIMIZED_HALLOWEEN_PROTECTION med databasomfattning:

ALTER DATABASE SCOPED CONFIGURATION SET OPTIMIZED_HALLOWEEN_PROTECTION = OFF;

Använda optimerat Halloween-skydd via frågetips

Du kan använda frågetipsen ENABLE_OPTIMIZED_HALLOWEEN_PROTECTION och DISABLE_OPTIMIZED_HALLOWEEN_PROTECTION för att aktivera och inaktivera optimerat Halloween-skydd för en viss fråga. Tipsen måste anges via USE HINT -satsen. Mer information finns i Frågetips (Transact-SQL).

Indikationerna fungerar under valfri kompatibilitetsnivå och åsidosätter konfigurationen på databasnivå OPTIMIZED_HALLOWEEN_PROTECTION.

Frågetipsen ENABLE_OPTIMIZED_HALLOWEEN_PROTECTION och DISABLE_OPTIMIZED_HALLOWEEN_PROTECTION kan anges direkt i frågan eller via Query Store-tips.

Optimerad Halloween-skyddsegenskap i frågeplanen

När optimerat Halloween-skydd används för en operatör i frågeplanen är OptimizedHalloweenProtectionUsed egenskapen för operatorn i XML-frågeplanen inställd på True.

Så här fungerar optimerat Halloween-skydd

När ADR är aktiverat får varje sats i en transaktion en unik satsidentifierare, som kallas nest ID. Varje rad som ändras av en DML-sats är stämplad med nest ID för satsen. Detta krävs för att tillhandahålla ACID-transaktionssemantiken med ADR.

När databasmotorn läser data under bearbetningen av DML-instruktionen hoppar den över alla rader som har samma kapslings-ID som den aktuella DML-instruktionen. ** Det innebär att frågeprocessorn inte ser de rader som redan bearbetats av uttrycket, för att undvika Halloween-problemet.

Begränsningar för optimerat Halloween-skydd

Optimerat Halloween-skydd används för närvarande inte i följande fall:

  • I en DML-instruktion som modifierar
    • En tillfällig tabell, en tabellvariabel eller en icke-temporär tabell i tempdb databasen.
    • En tabell med antingen klustrat eller icke-grupperat kolumnlagringsindex.
    • En graftabell eller en transaktionsregistertabell .
    • En vy som skapats med alternativet CHECK .
    • En tabell när tabellen eller en kolumn i tabellen har en kontrollbegränsning som använder en användardefinierad skalärfunktion.
    • En tabell som har en säkerhetsprincip på radnivå med antingen ett block eller ett filterpredikat.
    • En tabell som har en kolumn med attributet FILESTREAM .
  • I DELETE- och MERGE-instruktioner som innehåller OUTPUT-klause.
  • I MERGE och UPDATE ... FROM -instruktioner som kan ändra samma rad mer än en gång.

I alla dessa fall används det traditionella Halloween-skyddet med en Spool-operator (eller en annan blockeringsoperator om det redan finns) i stället.

Om samma DML-instruktion ändrar flera tabeller i olika databaser används optimerat Halloween-skydd endast för operatorer som ändrar tabeller i de databaser där optimerat Halloween-skydd är aktiverat. Till exempel kan både det optimerade och traditionella Halloween-skyddet ske i en sammansättningsbar DML-instruktion med en OUTPUT sats som infogar data i en tabell i en annan databas.

Relaterat innehåll