Gedetailleerde intelligente functies voor queryverwerking

Van toepassing op:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceSQL-database in Microsoft Fabric Preview

Dit artikel bevat uitgebreide beschrijvingen van verschillende IQP-functies (Intelligent Query Processing), releaseopmerkingen en meer details. De iqp-functiefamilie (Intelligent Query Processing) bevat functies met een brede impact die de prestaties van bestaande workloads verbeteren met minimale implementatie-inspanning die moet worden geïmplementeerd.

U kunt ervoor zorgen dat workloads automatisch in aanmerking komen voor intelligente queryverwerking door het toepasselijke databasecompatibiliteitsniveau voor de database in te schakelen. U kunt dit instellen met Behulp van Transact-SQL. Als u bijvoorbeeld het compatibiliteitsniveau van een database wilt instellen op SQL Server 2022 (16.x):

ALTER DATABASE [WideWorldImportersDW] SET COMPATIBILITY_LEVEL = 160;

Zie voor meer informatie over wijzigingen die zijn geïntroduceerd met nieuwe versies:

• Wat is nieuw in SQL Server 2017
• nieuwe functies in SQL Server 2019
• Wat is er nieuw in SQL Server 2022

Adaptieve joins in batchmodus

Van toepassing op: SQL Server (vanaf SQL Server 2017 (14.x)), Azure SQL Database

Met de functie Adaptieve Joins in de batchmodus kunt u kiezen tussen een Hash Join- of Geneste Loops Join-methode, die wordt uitgesteld tot nadat de eerste invoer is gescand, door gebruik te maken van een enkel plan dat in de cache is opgeslagen. De Adaptive Join-operator definieert een drempelwaarde die wordt gebruikt om te bepalen wanneer moet worden overgeschakeld naar een plan voor geneste lussen. Uw plan kan daarom dynamisch overschakelen naar een betere joinstrategie tijdens de uitvoering.

Zie Adaptieve joins begrijpen voor meer informatie, waaronder het uitschakelen van adaptieve joins zonder het compatibiliteitsniveau te wijzigen.

Interleaved-uitvoering voor MSTVFs

Van toepassing op: SQL Server (vanaf SQL Server 2017 (14.x)), Azure SQL Database

Een tabelwaardefunctie met meerdere instructies (MSTVF) is een type door de gebruiker gedefinieerde functie die parameters kan accepteren, meerdere T-SQL-instructies en RETURN een tabel kan uitvoeren.

Gelaagde uitvoering helpt om prestatieproblemen met workloads op te lossen die worden veroorzaakt door vaste kardinaliteitschattingen die zijn verbonden aan MSTVF's. Bij interleaved uitvoering worden de werkelijke rijaantallen van de functie gebruikt om beter geïnformeerde beslissingen te nemen over downstreamqueryplannen.

MSTVF's hebben een vaste kardinaliteits schatting van 100 vanaf SQL Server 2014 (12.x) en 1 voor eerdere SQL Server-versies.

Interleaved execution wijzigt de unidirectionele grens tussen de optimalisatie- en uitvoeringsfasen voor een uitvoering met één query en stelt plannen in staat om aan te passen op basis van de herziene kardinaliteitschattingen. Tijdens de optimalisatie, wanneer de database-engine een kandidaat voor interleaved uitvoering tegenkomt die gebruikmaakt van multi-statement tabelwaardefuncties (MSTVF's), wordt de optimalisatie onderbroken, wordt de toepasselijke substructuur uitgevoerd, worden nauwkeurige kardinaliteitschattingen vastgelegd en vervolgens wordt de optimalisatie hervat voor downstreambewerkingen.

In de volgende afbeelding ziet u de uitvoer van livequerystatistieken , een subset van een algemeen uitvoeringsplan met de impact van vaste kardinaliteitschattingen van MSTVF's

U kunt de werkelijke rijenstroom versus de geschatte rijen zien. Er zijn drie belangrijke gebieden van het plan (stroom is van rechts naar links):

• De MSTVF-tabelscan heeft een vaste schatting van 100 rijen. In dit voorbeeld zijn er echter 527.597 rijen die door deze MSTVF-tabelscan stromen, zoals te zien is in Live Query Statistics via de 527597 van 100 werkelijke schattingen, zodat de vaste schatting aanzienlijk scheef is.
• Voor de bewerking Geneste lussen wordt ervan uitgegaan dat er slechts 100 rijen worden geretourneerd door de buitenste zijde van de koppeling. Gezien het grote aantal rijen dat daadwerkelijk wordt geretourneerd door de MSTVF, bent u waarschijnlijk beter af met een geheel ander joinalgoritme.
• Voor de hash-overeenkomstbewerking ziet u het kleine waarschuwingssymbool, dat in dit geval een overloop naar schijf aangeeft.

Vergelijk het voorgaande plan met het werkelijke plan dat is gegenereerd met interleaved uitvoering ingeschakeld:

• U ziet dat de MSTVF-tabelscan nu een nauwkeurige kardinaliteitsraming weerspiegelt. Let ook op het opnieuw ordenen van deze tabelscan en de andere bewerkingen.
• En met betrekking tot join-algoritmen zijn we overgeschakeld van een Nested Loop-bewerking naar een Hash Match-bewerking, wat optimaler is gezien het grote aantal betrokken rijen.
• Merk ook op dat we geen spill-waarschuwingen meer hebben, omdat we meer geheugen toewijzen op basis van het werkelijke aantal rijen dat voortkomt uit de MSTVF-tabelscan.

In aanmerking komende instructies voor interleaved-uitvoering

MSTVF-referentieverklaringen in interleaved-uitvoering moeten momenteel alleen-lezen zijn en mogen geen deel uitmaken van een gegevenswijzigingoperatie. MSTVF's komen ook niet in aanmerking voor interleaved-uitvoering als ze geen runtimeconstanten gebruiken.

Voordelen van interleaved-uitvoering

Hoe groter de afwijking tussen het geschatte en het werkelijke aantal rijen, in combinatie met het aantal downstreamplanbewerkingen, hoe groter de invloed op de prestaties.

In het algemeen profiteren query's van interleaved uitvoering wanneer:

• Er is een grote scheefheid tussen het geschatte versus het werkelijke aantal rijen voor de tussenliggende resultatenset (in dit geval de MSTVF).
• En de algehele query is gevoelig voor een wijziging in de grootte van het tussenliggende resultaat. Dit gebeurt meestal wanneer er een complexe structuur boven die substructuur in het queryplan staat. Een eenvoudige SELECT * van een MSTVF profiteert niet van interleaved uitvoering.

Interleaved uitvoeringsoverhead

De overhead moet minimaal tot geen zijn. MSTVF's werden al gerealiseerd vóór de introductie van interleaved-uitvoering, maar het verschil is dat we op dit moment uitgestelde optimalisatie toestaan en daarna de kardinaliteitsschatting van de verwezenlijkte rijenset gebruiken. Net als bij elk plan dat van invloed is op wijzigingen, kunnen sommige plannen zodanig veranderen dat we met een betere kardinaliteit voor de substructuur een slechter plan krijgen voor de query over het algemeen. Risicobeperking kan bestaan uit het terugdraaien van het compatibiliteitsniveau of het gebruik van Query Store om de versie van het plan zonder regressie af te dwingen.

Afgewisselde uitvoering en opeenvolgende uitvoeringen

Zodra een door elkaar lopend uitvoeringsplan is gecachet, wordt het plan met de herziene schattingen voor de eerste uitvoering gebruikt voor opeenvolgende uitvoeringen zonder het opnieuw te doen.

Activiteit van ingebedde uitvoering bijhouden

U kunt gebruikskenmerken bekijken in het werkelijke uitvoeringsplan voor query's:

U kunt ook interleaved uitvoeringen bijhouden via de volgende uitgebreide gebeurtenissen:

Een query moet worden uitgevoerd om versprongen uitvoering mogelijk te maken en om de kardinaliteitsramingen van MSTVF te herzien. Het geschatte uitvoeringsplan wordt echter nog steeds weergegeven wanneer er gekruiste uitvoeringskandidaten zijn via het kenmerk ContainsInterleavedExecutionCandidates showplan.

Tussentijds uitvoeren caching

Als een plan wordt gewist of verwijderd uit de cache, is er bij het uitvoeren van query's een nieuwe compilatie die gebruikmaakt van interleaved-uitvoering. Met een stelling maakt OPTION (RECOMPILE) u een nieuw plan met interleaved execution, zonder het in de cache op te slaan.

Verstrengelde uitvoering en Query Store-interoperabiliteit

Plannen die gebruikmaken van interleaved uitvoering, kunnen worden geforceerd. Het plan is de versie die kardinaliteitsramingen heeft gecorrigeerd op basis van de initiële uitvoering.

Interleaved-uitvoering uitschakelen zonder het compatibiliteitsniveau te wijzigen

Interleaved-uitvoering kan worden uitgeschakeld op het database- of statement-niveau, en toch het databasecompatibiliteitsniveau van 140 of hoger wordt behouden. Als u interleaved uitvoering wilt uitschakelen voor alle queryuitvoeringen die afkomstig zijn van de database, voert u het volgende uit binnen de context van de toepasselijke database:

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

Wanneer deze instelling is ingeschakeld, wordt deze instelling weergegeven als ingeschakeld in sys.database_scoped_configurations. Als u interleaved uitvoering opnieuw wilt inschakelen voor alle queryuitvoeringen die afkomstig zijn van de database, voert u het volgende uit binnen de context van de toepasselijke database:

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

U kunt de interleaved-uitvoering voor een specifieke query ook uitschakelen door DISABLE_INTERLEAVED_EXECUTION_TVF als een hint voor de USE HINT-query aan te wijzen. Voorbeeld:

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

Een USE HINT-queryhint heeft voorrang op een database-specifieke configuratie of traceringsvlaggen.

Scalaire UDF-inlining

Van toepassing op: SQL Server (vanaf SQL Server 2019 (15.x)), Azure SQL Database

Scalaire UDF-inlining transformeert automatisch scalaire UDF's in relationele expressies. Deze worden ingesloten in de aanroepende SQL-query. Deze transformatie verbetert de prestaties van workloads die profiteren van scalaire UDF's. Scalar UDF-inlining vereenvoudigt kostengebaseerde optimalisatie van bewerkingen binnen UDF's. De resultaten zijn efficiënt, setgeoriënteerd en parallel in plaats van inefficiënte, iteratieve, seriële uitvoeringsplannen. Deze functie is standaard ingeschakeld onder databasecompatibiliteitsniveau 150 of hoger.

Zie Scalar UDF inlining voor meer informatie.

Tabelvariabele uitgestelde compilatie

Van toepassing op: SQL Server (vanaf SQL Server 2019 (15.x)), Azure SQL Database

De uitgestelde compilatie van tabelvariabelen verbetert de kwaliteit van het plan en de algehele prestaties voor query's die verwijzen naar tabelvariabelen. Tijdens de optimalisatie en de eerste planningscompilatie worden met deze functie kardinaliteitschattingen doorgegeven die zijn gebaseerd op het werkelijke aantal tabelvariabelerijen. Deze exacte gegevens over het aantal rijen worden vervolgens gebruikt voor het optimaliseren van downstreamplanbewerkingen.

Bij uitgestelde compilatie van tabelvariabelen wordt de compilatie van een instructie die verwijst naar een tabelvariabele uitgesteld tot de eerste werkelijke uitvoering van de instructie. Dit uitgestelde compilatiegedrag is identiek aan het gedrag van tijdelijke tabellen. Deze wijziging resulteert in het gebruik van de werkelijke kardinaliteit in plaats van de oorspronkelijke schatting van één rij.

Als u uitgestelde compilatie van tabelvariabelen wilt inschakelen, schakelt u databasecompatibiliteitsniveau 150 of hoger in voor de database waarmee u verbinding hebt wanneer de query wordt uitgevoerd.

Uitgestelde compilatie van tabelvariabelen verandert geen andere kenmerken van tabelvariabelen. Met deze functie worden bijvoorbeeld geen kolomstatistieken toegevoegd aan tabelvariabelen.

Uitgestelde compilatie van tabelvariabelen verhoogt de hercompilatiefrequentie niet. In plaats daarvan verschuift het waar de eerste compilatie plaatsvindt. Het resulterende cacheplan wordt gegenereerd op basis van de oorspronkelijke rijtelling van de compilatietabel met vertraagde variabelen. Het plan in de cache wordt opnieuw gebruikt door opeenvolgende query's. Het wordt opnieuw gebruikt totdat het plan wordt verwijderd of opnieuw wordt gecompileerd.

Het aantal rijen van tabelvariabelen dat wordt gebruikt voor de initiële compilatie van het plan, vertegenwoordigt een typische waarde die anders kan zijn dan een schatting van een vast aantal rijen. Als het anders is, zullen downstreambewerkingen ervan profiteren. De prestaties worden mogelijk niet verbeterd door deze functie als het aantal rijen in de tabelvariabele aanzienlijk varieert bij uitvoeringen.

Uitgestelde compilatie van tabelvariabelen uitschakelen zonder het compatibiliteitsniveau te wijzigen

Schakel de uitgestelde tabelvariabelecompilatie uit op het niveau van de database of instructie, terwijl u nog steeds het databasecompatibiliteitsniveau van 150 en hoger handhaaft. Als u de uitgestelde compilatie van tabelvariabelen wilt uitschakelen voor alle queryuitvoeringen die afkomstig zijn van de database, voert u het volgende voorbeeld uit binnen de context van de toepasselijke database:

ALTER DATABASE SCOPED CONFIGURATION SET DEFERRED_COMPILATION_TV = OFF;

Voer het volgende voorbeeld uit binnen de context van de relevante database om de uitgestelde compilatie van tabelvariabelen opnieuw in te schakelen voor alle query-uitvoeringen die vanuit de database worden uitgevoerd.

ALTER DATABASE SCOPED CONFIGURATION SET DEFERRED_COMPILATION_TV = ON;

U kunt ook de uitgestelde compilatie van tabelvariabelen uitschakelen voor een specifieke query door DISABLE_DEFERRED_COMPILATION_TV in te stellen als gebruikssuggestie. Voorbeeld:

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

Optimalisatie van parametergevoeligheidsplan

van toepassing op: SQL Server 2022 (16.x) Azure SQL DatabaseAzure SQL Managed Instance

De optimalisatie van het parameter-gevoeligheidsplan (PSP) maakt deel uit van de intelligente queryverwerkingsfamilie van functionaliteiten. Het adresseert het scenario waarin één plan in de cache voor een geparameteriseerde query niet optimaal is voor alle mogelijke binnenkomende parameterwaarden. Dit is het geval bij niet-uniforme gegevensdistributies.

• Zie parametergevoelige planoptimalisatie voor meer informatie over PSP-optimalisatie.
• Zie Parametergevoeligheid en Parameters en Hergebruik van uitvoeringsplannen voor meer informatie over parameterisatie en parametergevoeligheid.

Queryverwerking bij benadering

Approximatieve queryverwerking is een nieuwe functiefamilie. Het aggregert over grote gegevenssets, waarbij reactiesnelheid belangrijker is dan absolute precisie. Een voorbeeld is het berekenen van een COUNT(DISTINCT()) rij van meer dan 10 miljard rijen voor weergave op een dashboard. In dit geval is absolute precisie niet belangrijk, maar reactiesnelheid is essentieel.

Geschat Aantal Unieke

Van toepassing op: SQL Server (vanaf SQL Server 2019 (15.x)), Azure SQL Database

De nieuwe APPROX_COUNT_DISTINCT statistische functie retourneert het geschatte aantal unieke niet-null-waarden in een groep.

Deze functie is beschikbaar vanaf SQL Server 2019 (15.x), ongeacht het compatibiliteitsniveau.

Zie APPROX_COUNT_DISTINCT (Transact-SQL) voor meer informatie.

Percentiel bij benadering

van toepassing op: SQL Server (vanaf SQL Server 2022 (16.x)), Azure SQL Database

Deze aggregatiefuncties berekenen percentielen voor een grote gegevensset met acceptabele rang-gebaseerde foutgrenzen om snelle beslissingen te vergemakkelijken door gebruik te maken van benaderende percentiel-aggregatiefuncties.

Zie APPROX_PERCENTILE_DISC (Transact-SQL) en APPROX_PERCENTILE_CONT (Transact-SQL) voor meer informatie

Batchmodus voor rijopslag

Van toepassing op: SQL Server (vanaf SQL Server 2019 (15.x)), Azure SQL Database

Met batchmodus in rowstore kunt u batchmodus uitvoeren voor analyseworkloads zonder dat u columnstore-indexen nodig hebt. Deze functie biedt ondersteuning voor uitvoering in batchmodus, bitmapfilters voor opschijfheaps, en B-tree-indexen. De Batch-modus in rowstore biedt ondersteuning voor alle bestaande operators met batchmodus.

Overzicht van uitvoering van batchmodus

SQL Server 2012 (11.x) heeft een nieuwe functie geïntroduceerd om analytische workloads te versnellen: columnstore-indexen. De use cases en prestaties van columnstore-indexen zijn toegenomen in elke volgende release van SQL Server. Het maken van columnstore-indexen op tabellen kan de prestaties voor analytische workloads verbeteren. Er zijn echter twee gerelateerde maar afzonderlijke sets technologieën:

• Met columnstore-indexen hebben analytische query's alleen toegang tot de gegevens in de kolommen die ze nodig hebben. Paginacompressie in de columnstore-indeling is ook effectiever dan compressie in traditionele rowstore-indexen .
• Met batchmodusverwerking verwerken queryoperators gegevens efficiënter. Ze werken aan een batch rijen in plaats van één rij tegelijk. Veel andere schaalbaarheidsverbeteringen zijn gekoppeld aan batchmodusverwerking. Zie Uitvoeringsmodi voor meer informatie over de batchmodus.

De twee sets functies werken samen om de invoer/uitvoer (I/O) en het CPU-gebruik te verbeteren:

• Door columnstore-indexen te gebruiken, past meer van uw gegevens in het geheugen. Dit vermindert de I/O-workload.
• Batchmodusverwerking maakt efficiënter gebruik van CPU.

De twee technologieën profiteren waar mogelijk van elkaar. Aggregaties in de batchmodus kunnen bijvoorbeeld worden geëvalueerd als onderdeel van een columnstore-indexscan. Ook columnstore-gegevens die worden gecomprimeerd, worden veel efficiënter verwerkt met behulp van run-length-codering, batchmodus-joins en batchmodus-aggregaties.

Het is echter belangrijk om te begrijpen dat de twee functies onafhankelijk zijn:

• U kunt rijmodusplannen ophalen die gebruikmaken van columnstore-indexen.
• U kunt batchmodusplannen verkrijgen die uitsluitend rowstore-indexen gebruiken.

Meestal krijgt u de beste resultaten wanneer u de twee functies samen gebruikt. Vóór SQL Server 2019 (15.x) beschouwde de SQL Server-queryoptimizer alleen batchmodusverwerking voor query's die ten minste één tabel met een columnstore-index bevatten.

Columnstore-indexen zijn mogelijk niet geschikt voor sommige toepassingen. Een toepassing kan een andere functie gebruiken die niet wordt ondersteund met columnstore-indexen. In-place wijzigingen zijn bijvoorbeeld niet compatibel met columnstore-compressie. Triggers worden daarom niet ondersteund in tabellen met geclusterde columnstore-indexen. Belangrijker is het dat columnstore-indexen extra belasting toevoegen voor DELETE en UPDATE-instructies.

Voor sommige hybride, transactionele-analytische workloads wegen de nadelen van een transactionele workload zwaarder dan de voordelen van het gebruik van columnstore-indexen. Dergelijke scenario's kunnen profiteren van verbeterd CPU-gebruik door alleen batchmodusverwerking te gebruiken. Daarom bekijkt de functie batchmodus-op-rowstore de batchmodus voor alle queries, ongeacht het type index dat wordt gebruikt.

Workloads die kunnen profiteren van batchmodus in rowstore

De volgende workloads kunnen profiteren van de batchmodus in rowstore:

• Een belangrijk deel van de workload bestaat uit analytische query's. Deze query's maken meestal gebruik van operators zoals joins of aggregaties die honderdduizenden rijen of meer verwerken.
• De werkbelasting is afhankelijk van de CPU. Als het knelpunt I/O is, wordt het nog steeds aanbevolen om waar mogelijk een columnstore-index te overwegen.
• Als u een columnstore-index maakt, wordt er te veel overhead toegevoegd aan het transactionele deel van uw workload. Of het maken van een columnstore-index is niet haalbaar omdat uw toepassing afhankelijk is van een functie die nog niet wordt ondersteund met columnstore-indexen.

Welke veranderingen treden op met batchmodus in rowstore?

Voor batchmodus in rowstore is database vereist voor compatibiliteitsniveau 150.

Zelfs als een query geen toegang heeft tot tabellen met columnstore-indexen, gebruikt de queryprocessor heuristiek om te bepalen of batchmodus moet worden overwogen. De heuristiek bestaat uit deze controles:

1. Een eerste controle van tabelgrootten, gebruikte operators en geschatte kardinaliteiten in de invoerquery.
2. Aanvullende controlepunten, omdat de optimizer nieuwe, goedkopere abonnementen voor de query detecteert. Als deze alternatieve plannen geen significant gebruik maken van de batchmodus, stopt de optimizer met het verkennen van alternatieven voor batchmodus.

Als de batchmodus in rowstore wordt gebruikt, ziet u de werkelijke uitvoeringsmodus als batchmodus in het queryplan. De scanoperator maakt gebruik van de batchmodus voor schijf-heaps en B-tree-indexen. Deze scan in batchmodus kan bitmapfilters in batchmodus evalueren. Mogelijk ziet u ook andere batchmodusoperators in het plan. Voorbeelden zijn hash-joins, op hash gebaseerde aggregaties, sorteringen, vensteraggregaties, filters, samenvoeging en scalaire rekenoperators.

Remarks

Queryplannen maken niet altijd gebruik van batchmodus. Query Optimizer kan besluiten dat de batchmodus niet nuttig is voor de query.

De zoekruimte van de Query Optimizer wordt gewijzigd. Dus als u een plan in rijmodus krijgt, is het misschien niet hetzelfde als het plan dat u krijgt bij een lager compatibiliteitsniveau. En als u een batchmodusplan krijgt, is dit mogelijk niet hetzelfde als het plan dat u krijgt met een kolomopslagindex.

Plannen kunnen ook worden gewijzigd voor query's die columnstore- en rowstore-indexen combineren vanwege de nieuwe rijopslagscan in batchmodus.

Er gelden huidige beperkingen voor de nieuwe batchmodus voor het scannen van rijenopslag:

• Het wordt niet geactiveerd voor geheugen-OLTP-tabellen of voor een andere index dan heaps op schijf en B-trees.
• Het wordt ook niet geactiveerd als een grote object (LOB) kolom wordt opgehaald of gefilterd. Deze beperking omvat schaarse kolomsets en XML-kolommen.

Er zijn query's waarvoor de batchmodus niet wordt gebruikt, zelfs niet voor columnstore-indexen. Voorbeelden zijn query's die betrekking hebben op cursors. Dezelfde uitsluitingen worden ook uitgebreid naar de batchmodus in rowstore.

Batchmodus configureren voor rowstore

De BATCH_MODE_ON_ROWSTORE configuratie van het databasebereik is standaard INGESCHAKELD.

U kunt de batchmodus in rowstore uitschakelen zonder het compatibiliteitsniveau van de database te wijzigen:

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

U kunt de batchmodus in rowstore uitschakelen via de configuratie van het databasebereik. Maar u kunt de instelling op queryniveau nog steeds overschrijven met behulp van de ALLOW_BATCH_MODE queryhint. In het volgende voorbeeld wordt batchmodus op rowstore ingeschakeld, zelfs als deze functie is uitgeschakeld via de configuratie die van toepassing is op de database.

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

U kunt de batchmodus ook uitschakelen op rowstore voor een specifieke query met behulp van de DISALLOW_BATCH_MODE query hint. Zie het volgende voorbeeld:

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

Feedbackfuncties voor queryverwerking

De feedbackfuncties voor het verwerken van query's maken deel uit van de reeks functies voor intelligente queryverwerking.

Queryverwerking is een proces waarmee de queryprocessor in SQL Server, Azure SQL Database en Azure SQL Managed Instance historische gegevens over de uitvoering van een query gebruikt om te bepalen of de query hulp kan ontvangen van een of meer wijzigingen in de manier waarop deze wordt gecompileerd en uitgevoerd. De prestatiegegevens worden verzameld in de Query Store, met verschillende suggesties om de uitvoering van query's te verbeteren. Als dit lukt, worden deze wijzigingen op de schijf, in het geheugen en/of in de Query Store bewaard voor toekomstig gebruik. Als de suggesties niet voldoende verbetering opleveren, worden ze verwijderd en wordt de query nog steeds uitgevoerd zonder die feedback.

Voor informatie over welke queryverwerking feedbackfuncties beschikbaar zijn in verschillende versies van SQL Server, of in Azure SQL Database of Azure SQL Managed Instance, zie Intelligente queryverwerking in SQL-databases of de volgende artikelen voor elke feedbackfunctie.

Feedback voor geheugentoewijzing

Feedback over geheugentoekenning is in fasen geïntroduceerd in de afgelopen grote releases van SQL Server.

Feedback geven over geheugen in batchmodus

Voor informatie over feedback bij het geheugenverlenen in Batch-modus, bezoek Batch mode memory grant feedback.

Feedback voor geheugen toekenning in rijmodus

Voor informatie over feedback voor geheugentoekenning in rijmodus, ga naar Row mode memory grant feedback.

Feedback over geheugentoewijzing met percentiel- en persistentiemodus.

Voor informatie over feedback over geheugentoekenning in de percentiel- en persistentiemodus, bezoek Feedback over geheugentoekenning in de percentiel- en persistentiemodus.

Feedback over mate van parallelle uitvoering (DOP)

Ga voor meer informatie over feedback over de mate van parallelisme (DOP) naar Feedback over de mate van parallelisme (DOP).

Feedback bij kardinaliteitsinschatting (CE)

Bezoek feedback over kardinaliteitschatting (CE) voor informatie over CE-feedback.

Geoptimaliseerd plan afdwingen met Query Store

Raadpleeg voor informatie over geoptimaliseerd plan afdwingen met Query Store Geoptimaliseerd plan afdwingen met Query Store.

Verwante inhoud

• Joins (SQL Server)
• Uitvoeringsmodi
• architectuurhandleiding voor verwerking van query's
• Showplan Verwijzing naar Logische en Fysieke Operatoren
• ALTER DATABASE SCOPED CONFIGURATION(Transact-SQL)
• Wat is nieuw in SQL Server 2017
• nieuwe functies in SQL Server 2019
• Wat is er nieuw in SQL Server 2022
• Intelligente queryverwerking demonstreren
• Constante Vouwen en Expressie-evaluatie
• Demo's voor intelligente queryverwerking op GitHub
• Prestatiecentrum voor SQL Server Database Engine en Azure SQL Database
• Prestaties controleren via de Query Store
• Aanbevolen procedures voor het bewaken van workloads met Query Store