Feedback bij kardinaliteitsinschatting (CE)

Van toepassing op:Van toepassing op: SQL Server 2022 (16.x) en latere versies, Azure SQL Database, Azure SQL Managed Instance.

Vanaf SQL Server 2022 (16.x) maakt CE-feedback (Kardinaliteitschatting) deel uit van het intelligente queryverwerkingsfamilie van functies en biedt oplossingen voor suboptimale uitvoeringsplannen van herhalende query's wanneer deze problemen het gevolg zijn van onjuiste aannames van het CE-model. Dit scenario helpt bij het verminderen van regressierisico's met betrekking tot de standaard-CE bij het upgraden van oudere versies van de database-engine.

Omdat er geen enkele set CE-modellen en veronderstellingen geschikt is voor de enorme reeks workloads en gegevensdistributies van klanten, biedt CE-feedback een aanpasbare oplossing op basis van de kenmerken van queryruntime. CE-feedback identificeert en gebruikt een modelveronderstelling die beter past bij een bepaalde query en gegevensdistributie om de kwaliteit van het queryuitvoeringsplan te verbeteren. Op dit moment kan CE-feedback planoperatoren identificeren waarbij het geschatte aantal rijen en het werkelijke aantal rijen heel verschillend zijn. Feedback wordt toegepast wanneer er aanzienlijke fouten optreden bij het schatten van modellen en er is een levensvatbaar alternatief model om te proberen.

Voor andere functies voor queryfeedback, zie Feedback over geheugentoewijzing en Feedback over de mate van parallelisme (DOP).

Feedback over kardinaliteitschatting (CE) begrijpen

Kardinaliteitschatting (CE) is hoe de Query Optimizer het totale aantal rijen kan schatten dat op elk niveau van een queryplan wordt verwerkt. De schatting van kardinaliteit in SQL Server wordt voornamelijk afgeleid van histogrammen die zijn gemaakt wanneer indexen of statistieken worden gemaakt, hetzij handmatig of automatisch. Soms maakt SQL Server ook gebruik van beperkingsgegevens en logische herschrijven van query's om de kardinaliteit te bepalen.

Verschillende versies van de database-engine maken gebruik van verschillende CE-modelveronderstellingen op basis van hoe gegevens worden gedistribueerd en opgevraagd. Zie de versies van de CE voor meer informatie.

Feedback-implementatie van kardinaliteitschatting (CE)

Feedback over kardinaliteitschatting (CE) leert welke CE-modelveronderstellingen in de loop van de tijd optimaal zijn en past vervolgens de historisch meest correcte aanname toe:

CE-feedback identificeert modelgerelateerde veronderstellingen en evalueert of ze nauwkeurig zijn voor herhalende query's.
Als een aanname onjuist lijkt, wordt een volgende uitvoering van dezelfde query getest met een queryplan dat de impactvolle CE-modelveronderstelling aanpast en controleert of dit helpt. We identificeren onjuistheid door te kijken naar werkelijke versus geschatte rijen van planoperators. Niet alle fouten kunnen worden gecorrigeerd door modelvarianten die beschikbaar zijn in CE-feedback.
Als het de kwaliteit van het plan verbetert, wordt het oude queryplan vervangen door een queryplan met de juiste USE HINT-queryhint waarmee het schattingsmodel wordt aangepast, geïmplementeerd via het Query Store-hintmechanisme.

Alleen geverifieerde feedback blijft behouden. CE-feedback wordt niet gebruikt voor die query als de aangepaste modelaanname resulteert in een prestatieregressie. In deze context wordt een door de gebruiker geannuleerde query ook beschouwd als een regressie.

Feedbackscenario's voor kardinaliteitschatting (CE)

Feedback van kardinaliteitschattingen (CE) heeft betrekking op waargenomen regressieproblemen als gevolg van onjuiste CE-modelveronderstellingen bij gebruik van de standaard CE (CE120 of hoger) en kan selectief verschillende modelveronderstellingen gebruiken. De scenario's omvatten Correlatie, Join Containment en Optimizer-rijdoel.

Feedbackcorrelatie van kardinaliteitschatting (CE)

Wanneer de Query Optimizer de selectiviteit van predicaten in een bepaalde tabel of weergave schat, of het aantal rijen dat voldoet aan het genoemde predicaat, wordt gebruikgemaakt van correlatiemodelveronderstellingen. Deze veronderstellingen kunnen betrekking hebben op predicaten:

Volledig onafhankelijk (standaard voor CE70), waarbij kardinaliteit wordt berekend door de selectiviteiten van alle predicaten te vermenigvuldigen.
Gedeeltelijk gecorreleerd (standaard voor CE120 en hoger), waarbij kardinaliteit wordt berekend met behulp van een variatie op exponentieel uitstel, waarbij de selectiviteiten van de meeste naar het minst selectieve predicaat worden geordend.
Volledig gecorreleerd, waarbij kardinaliteit wordt berekend met behulp van de minimale selectiviteiten voor alle predicaten.

In het volgende voorbeeld wordt gedeeltelijke correlatie gebruikt wanneer de databasecompatibiliteit is ingesteld op 120 of hoger:

USE AdventureWorks2016_EXT;
GO
SELECT AddressID, AddressLine1, AddressLine2
FROM Person.Address
WHERE StateProvinceID = 79 AND City = N'Redmond';
GO

Wanneer de databasecompatibiliteit is ingesteld op 160 en standaardcorrelatie wordt gebruikt, probeert CE-feedback de correlatie één stap voor stap naar de juiste richting te verplaatsen op basis van of de geschatte kardinaliteit is onderschat of overschat ten opzichte van het werkelijke aantal rijen. Gebruik volledige correlatie als een werkelijk aantal rijen groter is dan de geschatte kardinaliteit. Gebruik volledige onafhankelijkheid als een werkelijk aantal rijen kleiner is dan de geschatte kardinaliteit.

Zie de versies van de CE voor meer informatie.

Kardinaliteitschatting (CE) feedback-join-insluiting

Wanneer de Query Optimizer de selectiviteit van joinpredicaten en toepasselijke filterpredicaten schat, worden insluitingsmodelveronderstellingen gebruikt. Deze veronderstellingen zijn:

Bij eenvoudige insluiting (standaard voor CE70) wordt ervan uitgegaan dat joinpredicaten volledig zijn gecorreleerd, waarbij filterselectiviteit eerst wordt berekend en dat vervolgens de joinselectiviteit wordt meegerekend.
Bij basisbesluiting (standaard voor CE120 en hoger) wordt ervan uitgegaan dat er geen correlatie is tussen joinpredicaten en downstreamfilters, waarbij joinselectiviteit eerst wordt berekend en vervolgens wordt de filterselectiviteit meegerekend.

In het volgende voorbeeld wordt basisbesluiting gebruikt wanneer de databasecompatibiliteit is ingesteld op 120 of hoger:

USE AdventureWorksDW2016_EXT;
GO
SELECT *
FROM dbo.FactCurrencyRate AS f
INNER JOIN dbo.DimDate AS d ON f.DateKey = d.DateKey
WHERE d.MonthNumberOfYear = 7 AND f.CurrencyKey = 3 AND f.AverageRate > 1;
GO

Zie de versies van de CE voor meer informatie.

Feedback over kardinaliteitschatting (CE) en het rijfocus van de queryoptimizer

Wanneer de Query Optimizer de kardinaliteit van een uitvoeringsplan schat, wordt er meestal van uitgegaan dat alle in aanmerking komende rijen uit alle tabellen moeten worden verwerkt. Sommige querypatronen zorgen er echter voor dat queryoptimalisatie zoekt naar een plan dat een kleiner aantal rijen retourneert om I/O te verminderen. Als de query een doelaantal rijen (rijdoel) opgeeft dat tijdens runtime kan worden verwacht met behulp van een TOP, IN of EXISTS trefwoorden, de FAST queryhint of een SET ROWCOUNT instructie, wordt dat rijdoel gebruikt als onderdeel van het queryoptimalisatieproces, zoals in het volgende voorbeeld:

USE AdventureWorks2016_EXT;
GO
SELECT TOP 1 soh.*
FROM Sales.SalesOrderHeader AS soh
INNER JOIN Sales.SalesOrderDetail AS sod ON soh.SalesOrderID = sod.SalesOrderID;
GO

Wanneer het plan voor het rijdoel wordt toegepast, wordt het geschatte aantal rijen in het queryplan verminderd omdat de Query Optimizer ervan uitgaat dat een kleiner aantal rijen moet worden verwerkt om het rijdoel te bereiken.

Hoewel row-goal een nuttige optimalisatiestrategie is voor bepaalde querypatronen, kunnen er meer pagina's worden gescand dan geschat als de gegevens niet gelijkmatig zijn verdeeld, wat betekent dat de row-goal inefficiënt wordt. CE-feedback kan de rijdoelscan uitschakelen en een zoekopdracht inschakelen wanneer deze inefficiëntie wordt gedetecteerd.

In het uitvoeringsplan is er geen kenmerk specifiek voor CE-feedback, maar er is een kenmerk dat wordt vermeld voor de Query Store-hint. Zoek naar dat de QueryStoreStatementHintSourceCE feedback is.

Overwegingen voor feedback over kardinaliteitschatting (CE)

Als u feedback over kardinaliteitschatting (CE) wilt inschakelen, schakelt u databasecompatibiliteitsniveau 160 in voor de database waarmee u verbinding hebt bij het uitvoeren van de query. De Query Store moet ingeschakeld zijn en in READ_WRITE-modus voor elke database waarin CE-feedback wordt gebruikt.
Als u CE-feedback op databaseniveau wilt uitschakelen, gebruikt u de configuratie van het CE_FEEDBACKdatabasebereik. Bijvoorbeeld in de gebruikersdatabase:
```
ALTER DATABASE SCOPED CONFIGURATION SET CE_FEEDBACK = OFF;
```
Als u CE-feedback op queryniveau wilt uitschakelen, gebruikt u de DISABLE_CE_FEEDBACK queryhint.

CE-feedbackactiviteit is zichtbaar via de query_feedback_analysis- en query_feedback_validation-XEvents.

Hints die door CE-feedback zijn ingesteld, kunnen worden bijgehouden met behulp van de sys.query_store_query_hints catalogusweergave.

Feedbackgegevens kunnen worden bijgehouden met behulp van de sys.query_store_plan_feedback catalogusweergave.

Als een query een geforceerd queryplan heeft via de Query Store, wordt CE-feedback niet gebruikt voor die query.

Als een query gebruikmaakt van hints voor in code vastgelegde query's of als query store-hints worden gebruikt die door de gebruiker zijn ingesteld, wordt CE-feedback niet gebruikt voor die query. Voor meer informatie, zie query hints en Query Store hint.

Vanaf SQL Server 2022 (16.x) is CE-feedback niet replicabewust voor secundaire replica's in beschikbaarheidsgroepen wanneer Query Store voor secundaire replica's is ingeschakeld. CE-feedback biedt momenteel alleen voordelen voor primaire replica's. Bij failover gaat de feedback die wordt toegepast op primaire of secundaire replica's verloren. Query Store is beschikbaar op replica's van secundaire beschikbaarheidsgroepen vanaf SQL Server 2025 (17.x). Voor meer informatie, zie Query Store voor secundaire replica's.

Persistentie voor feedback over kardinaliteitschatting (CE)

Van toepassing op:Van toepassing op: SQL Server 2022 (16.x) en latere versies, Azure SQL Database, Azure SQL Managed Instance.

Feedback over kardinaliteitschatting (CE) kan scenario's detecteren wanneer de optimalisatie van rijdoel moet worden behouden en deze wijziging behouden door deze in de Query Store te behouden in de vorm van een Query Store-hint. De nieuwe optimalisatie wordt gebruikt voor toekomstige uitvoeringen van de query. CE-feedback komt voor in andere scenario's buiten querypatronen voor optimalisatie van rijdoel, zoals beschreven in feedbackscenario's. CE feedback verwerkt momenteel scenario's van predicaatselectiviteit die worden gebruikt door het correlatiemodel van de CE, en joinscenario's van predicaten die door het insluitingsmodel van de CE worden verwerkt.

Deze functie is geïntroduceerd in SQL Server 2022 (16.x), maar deze prestatieverbetering is beschikbaar voor query's die werken op databasecompatibiliteitsniveau 160 of hoger, of de QUERY_OPTIMIZER_COMPATIBILITY_LEVEL_n hint van 160 en hoger, en wanneer Query Store is ingeschakeld voor de database en de status Lezen schrijven heeft.

Bekende problemen met feedback voor kardinaliteitsschatting (CE)

Probleem	Datum ontdekt	Toestand	Datum opgelost
Trage prestaties van SQL Server nadat u cumulatieve update 8 hebt toegepast voor SQL Server 2022 (16.x) onder bepaalde voorwaarden. Het geheugengebruik van plancache kan dramatisch zijn, samen met onverwachte toenamen van het CPU-gebruik wanneer CE-feedback is ingeschakeld.	December 2023	Opgelost	22 april 2024 (CU 12)

Details van bekende problemen

Trage SQL Server-prestaties nadat u Cumulatieve Update 8 hebt toegepast voor SQL Server 2022 onder bepaalde voorwaarden

Vanaf SQL Server 2022 (16.x) Cumulatieve update 8 kan SQL Server onverwachte toenames vertonen in het CPU- en geheugengebruik. Daarnaast kan ook een toename van RESOURCE_SEMAPHORE_QUERY_COMPILE wachttijden worden waargenomen. Mogelijk merkt u ook een gestage toename van het aantal Plan Cache-objecten dat wordt gebruikt, terwijl u de plancachelimieten nadert en technieken zoals ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE, DBCC FREESYSTEMCACHE of DBCC FREEPROCCACHE geen oplossingen bieden bij het handmatig wissen van de plancache. Dit gedrag is slechts waargenomen door een paar klanten.

Dit probleem is niet van invloed op alle workloads en is afhankelijk van het aantal verschillende plannen dat is gegenereerd, evenals het aantal plannen dat in aanmerking komt voor de CE-feedbackfunctie. Hoewel CE-feedback planoperators analyseert op significante modelfoutinschattingen, is er een scenario waarin een plan waarnaar wordt verwezen tijdens deze analysefase kan worden gederefereerd. Deze situatie voorkomt dat het plan uit het geheugen wordt verwijderd met behulp van het gebruikelijke LRU-algoritme (Least Recently Used). Het LRU-mechanisme is één manier waarop SQL Server verwijderingsbeleid afdwingt. SQL Server verwijdert ook plannen uit het geheugen als het systeem onder geheugendruk staat. Wanneer SQL Server probeert de plannen te verwijderen die onjuist zijn ongedereferneerd, kan het deze plannen niet uit de plancache verwijderen, wat ervoor zorgt dat de cache blijft groeien. De groeiende cache kan leiden tot extra compilaties die uiteindelijk meer CPU en geheugen gebruiken. Zie Plan Cache Internals voor meer informatie.

Symptoom: Het aantal plancache-items in gebruik en zijn gemarkeerd als 'dirty' van zowel SQL-plannen als Object-plannen neemt in de loop van de tijd toe tot 50.000 of meer. Als u plancachevermeldingen bekijkt die dit niveau beginnen te benaderen, samen met onverwachte toename van het CPU-gebruik, kan dit probleem optreden. Er wordt een oplossing geboden met SQL Server 2022 (16.x) Cumulatieve update 12. Zie KB5033663.

Als u het aantal plancachevermeldingen wilt controleren dat door uw systeem wordt gebruikt, kunnen de volgende voorbeelden worden gebruikt als een momentopname van het aantal plancachevermeldingen dat bestaat. Als voorbeeld is het controleren van het aantal plancachevermeldingen die zijn gemarkeerd als vuil, periodiek over tijd een manier om te monitoren op dit fenomeen.

SELECT
  CASE
    WHEN mce.[name] LIKE 'SQL Plan%' THEN 'SQL Plans'
    WHEN mce.[name] LIKE 'Object Plan%' THEN 'Object Plans'
    ELSE '[All other cache stores]'
  END AS PlanType,
  COUNT(*) AS [Number of plans marked to be removed]
FROM sys.dm_os_memory_cache_entries AS mce
LEFT OUTER JOIN sys.dm_exec_cached_plans AS ecp
  ON mce.memory_object_address = ecp.memory_object_address
WHERE mce.is_dirty = 1
AND ecp.bucketid is NULL
GROUP BY
  CASE
    WHEN mce.[name] LIKE 'SQL Plan%' THEN 'SQL Plans'
    WHEN mce.[name] LIKE 'Object Plan%' THEN 'Object Plans'
    ELSE '[All other cache stores]'
  END;

Een andere set query's die ook dezelfde informatie bevatten als in het vorige voorbeeld, terwijl u ook aanvullende metrische prestatiegegevens kunt observeren. Trefferverhoudingen voor plancache nemen af, evenals het aantal compilaties ten opzichte van het aantal batchaanvragen per seconde. De volgende query's kunnen worden gebruikt om uw systeem in de loop van de tijd te bewaken. Houd de Cachetrefferverhouding (onverwachte dips) in de gaten, evenals de cacheobjecten die in gebruik zijn (aantallen die toenemen tot niveaus die 50.000 naderen zonder af te nemen), en een lagere dan verwachte verhouding van Batch-aanvragen/seconde vergeleken met een stijging van Compilaties/seconde.

--SQL Plan (Adhoc and Prepared plans)
SELECT
    CASE
        WHEN [counter_name] = 'Cache Hit Ratio' THEN 'Cache Hit Ratio'
        WHEN [counter_name] = 'Cache Object Counts' THEN 'Cache Object Counts'
        WHEN [counter_name] = 'Cache Objects in use' THEN 'Cache Objects in use'
        WHEN [counter_name] = 'Cache Pages' THEN 'Cache Pages'
    END AS [SQLServer:Plan Cache (SQL Plans)],
    CASE
        WHEN [counter_name] = 'Cache Hit Ratio' THEN NULL
        ELSE FORMAT(cntr_value, '#,###')
    END AS [Counter Value],
    CASE
        WHEN [counter_name] = 'Cache Hit Ratio' THEN
            FORMAT(TRY_CONVERT(DECIMAL(5, 2), (cntr_value * 1.0 / NULLIF((SELECT cntr_value
        FROM sys.dm_os_performance_counters WHERE
        [object_name] LIKE '%:Plan Cache%' AND [counter_name] = 'Cache Hit Ratio Base'
        AND instance_name LIKE 'SQL Plan%'), 0))), '0.00%')
    END AS [SQL Plan Cache Hit Ratio]
FROM sys.dm_os_performance_counters
WHERE [object_name] LIKE '%:Plan Cache%'
    AND [counter_name] IN ('Cache Hit Ratio', 'Cache Object Counts', 'Cache Objects in use', 'Cache Pages')
    AND instance_name LIKE 'SQL Plan%'
ORDER BY [counter_name];

--Module/Stored procedure based plans
SELECT
    CASE
        WHEN [counter_name] = 'Cache Hit Ratio' THEN 'Cache Hit Ratio'
        WHEN [counter_name] = 'Cache Object Counts' THEN 'Cache Object Counts'
        WHEN [counter_name] = 'Cache Objects in use' THEN 'Cache Objects in use'
        WHEN [counter_name] = 'Cache Pages' THEN 'Cache Pages'
    END AS [SQLServer:Plan Cache (Object Plans)],
    CASE
        WHEN [counter_name] = 'Cache Hit Ratio' THEN NULL
        ELSE FORMAT(cntr_value, '#,###')
    END AS [Counter Value],
    CASE
        WHEN [counter_name] = 'Cache Hit Ratio' THEN
            FORMAT(TRY_CONVERT(DECIMAL(5, 2), (cntr_value * 1.0 / NULLIF((SELECT cntr_value
        FROM sys.dm_os_performance_counters WHERE
        [object_name] LIKE '%:Plan Cache%' AND [counter_name] = 'Cache Hit Ratio Base'
        AND instance_name LIKE 'Object Plan%'), 0))), '0.00%')
    END AS [SQL Plan Cache Hit Ratio]
FROM sys.dm_os_performance_counters
WHERE [object_name] LIKE '%:Plan Cache%'
    AND [counter_name] IN ('Cache Hit Ratio', 'Cache Object Counts', 'Cache Objects in use', 'Cache Pages')
    AND instance_name LIKE 'Object Plan%'
ORDER BY [counter_name];

SELECT
    CASE
        WHEN [counter_name] = 'Batch Requests/sec' THEN 'Batch Requests/sec'
        WHEN [counter_name] = 'SQL Compilations/sec' THEN 'SQL Compilations/sec'
    END AS [SQLServer:SQL Statistics],
    FORMAT(cntr_value, '#,###') AS [Counter Value]
FROM sys.dm_os_performance_counters
WHERE [object_name] LIKE '%:SQL Statistics%'
AND counter_name IN ('Batch Requests/sec', 'SQL Compilations/sec'
);

Tijdelijke maatregel

Als uw systeem nog steeds de symptomen ondervindt die eerder zijn beschreven, kan de ce-feedbackfunctie na het toepassen van cumulatieve update 12 KB5033663 worden uitgeschakeld op databaseniveau.

Voor het vrijmaken van het cachegeheugen van het plan dat door dit probleem is gebruikt, is een herstart van het SQL Server-exemplaar vereist. Deze herstartactie kan worden uitgevoerd nadat de ce-feedbackfunctie is uitgeschakeld. Als u CE-feedback op databaseniveau wilt uitschakelen, gebruikt u de configuratie van het CE_FEEDBACKdatabasebereik. Bijvoorbeeld in de gebruikersdatabase:

ALTER DATABASE SCOPED CONFIGURATION SET CE_FEEDBACK = OFF;

Feedback en het melden van problemen

Voor feedback of vragen, e-mail CEFfeedback@microsoft.com

Feedback

Is deze pagina nuttig?

Last updated on 2025-11-19