Feedback sobre a estimativa de cardinalidade (CE)

Aplica-se a:Aplica-se a: SQL Server 2022 (16.x) e versões posteriores, Azure SQL Database, Azure SQL Managed Instance.

A partir do SQL Server 2022 (16.x), o feedback de Estimativa de Cardinalidade (CE) faz parte da família de funcionalidades de processamento inteligente de consultas e aborda planos de execução de consultas subótimos para consultas repetidas quando estes problemas resultam de suposições incorretas no modelo CE. Este cenário ajuda a reduzir os riscos de regressão relacionados com o CE padrão ao atualizar a partir de versões mais antigas do Motor de Base de Dados.

Como nenhum conjunto único de modelos e pressupostos de CE consegue acomodar a vasta gama de cargas de trabalho dos clientes e distribuições de dados, o feedback de CE fornece uma solução adaptável baseada nas características do tempo de execução da consulta. O feedback de CE identifica e utiliza uma suposição de modelo que melhor se ajusta a uma determinada consulta e distribuição de dados para melhorar a qualidade do plano de execução da consulta. Atualmente, o feedback CE pode identificar operadores de plano onde o número estimado de linhas e o número real de linhas são muito diferentes. O feedback é aplicado quando ocorrem erros significativos na estimativa do modelo, e existe um modelo alternativo viável a experimentar.

Para outras funcionalidades de feedback de consulta, consulte Feedback de concessão de memória e feedback de grau de paralelismo (DOP).

Compreenda o feedback da estimativa de cardinalidade (EC)

A estimativa de cardinalidade (CE) é a forma como o Otimizador de Consultas pode estimar o número total de linhas processadas em cada nível de um plano de consulta. A estimativa de cardinalidade no SQL Server é derivada principalmente de histogramas criados quando índices ou estatísticas são criados, seja manualmente ou automaticamente. Às vezes, o SQL Server também usa informações de restrição e regravações lógicas de consultas para determinar a cardinalidade.

Diferentes versões do Motor de Base de Dados usam pressupostos diferentes do modelo CE com base na forma como os dados são distribuídos e consultados. Para mais informações, consulte as versões do CE.

Implementação de feedback na estimativa de cardinalidade (CE)

O feedback de estimativa de cardinalidade (CE) aprende quais as suposições do modelo CE que são ótimas ao longo do tempo e depois aplica a suposição historicamente mais correta:

O feedback CE identifica pressupostos relacionados com modelos e avalia se são precisos para consultas repetidas.
Se uma suposição parecer incorreta, uma execução subsequente da mesma consulta é testada com um plano de consulta que ajusta a suposição impactante do modelo CE e verifica se ajuda. Identificamos incorreções analisando as linhas reais em comparação com as estimadas dos operadores de plano. Nem todos os erros podem ser corrigidos por variantes de modelo disponíveis no feedback CE.
Se melhorar a qualidade do plano, o antigo plano de consulta é substituído por um plano de consulta que utiliza o USE HINT query hint apropriado, que ajusta o modelo de estimativa, implementado através do mecanismo de dicas Query Store.

Apenas os comentários verificados são mantidos. O feedback de CE não é usado para essa consulta se a suposição ajustada do modelo resultar numa regressão de desempenho. Nesse contexto, uma consulta cancelada pelo usuário também é percebida como uma regressão.

Cenários de retroalimentação de estimativa de cardinalidade (CE)

O feedback de estimativa de cardinalidade (CE) aborda problemas identificados de regressão resultantes de pressupostos incorretos do modelo CE ao utilizar o modelo CE padrão (CE120 ou superior) e pode usar pressupostos de modelos diferentes de forma seletiva. Os cenários incluem Correlação, Contenção de Junção e objetivo de linha do Otimizador.

Correlação de feedback na estimativa de cardinalidade (EC)

Quando o Otimizador de Consultas estima a seletividade dos predicados numa dada tabela ou vista, ou o número de linhas que satisfaz o referido predicado, utiliza pressupostos do modelo de correlação. Estas suposições podem ser que os predicados são:

Totalmente independente (padrão para CE70), onde a cardinalidade é calculada multiplicando as seletivas de todos os predicados.
Parcialmente correlacionado (padrão para CE120 e superiores), onde a cardinalidade é calculada usando uma variação do recuo exponencial, ordenando as seletividades do maior para o predicado menos seletivo.
Totalmente correlacionado, onde a cardinalidade é calculada usando as seletivas mínimas para todos os predicados.

O exemplo seguinte utiliza correlação parcial quando a compatibilidade da base de dados está definida para 120 ou superior:

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

Quando a compatibilidade da base de dados é definida como 160 e é usada a correlação padrão, o feedback CE tenta mover a correlação para a direção correta, um passo de cada vez, com base em se a cardinalidade estimada foi subestimada ou sobrestimada em comparação com o número real de linhas. Use correlação total se o número real de linhas for maior do que a cardinalidade estimada. Use independência total se o número real de linhas for menor do que a cardinalidade estimada.

Para mais informações, consulte as versões do CE.

Contenção por retroalimentação da junção de estimativa de cardinalidade (CE)

Quando o Otimizador de Consultas estima a seletividade dos predicados de junção e dos predicados de filtro aplicáveis, utiliza pressupostos do modelo de contenção. Estas suposições são:

A contenção simples (padrão para CE70) assume que os predicados de junção estão totalmente correlacionados, onde a seletividade do filtro é calculada primeiro e depois a seletividade da junção é considerada.
A contenção base (padrão para CE120 e superiores) assume que não há correlação entre predicados de junção e filtros a jusante, onde a seletividade de junção é calculada primeiro e depois a seletividade do filtro é considerada.

O exemplo seguinte utiliza contenção de base quando a compatibilidade da base de dados está definida para 120 ou superior:

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

Para mais informações, consulte as versões do CE.

Feedback da estimativa de cardinalidade (CE) e o objetivo da linha do otimizador de consultas

Quando o Otimizador de Consultas estima a cardinalidade de um plano de execução, normalmente assume que todas as linhas qualificadas de todas as tabelas têm de ser processadas. No entanto, alguns padrões de consulta levam o Otimizador de Consultas a procurar um plano que devolve um número menor de linhas para reduzir a E/S. Se a consulta especificar um número alvo de linhas (objetivo de linhas) que poderia ser esperado em tempo de execução usando uma TOP, IN ou EXISTS palavra-chave, a FAST sugestão de consulta ou uma SET ROWCOUNT instrução, esse objetivo de linhas é usado como parte do processo de otimização da consulta, como no seguinte exemplo:

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

Quando o plano de meta de linhas é aplicado, o número estimado de linhas no plano de consulta é reduzido porque o Otimizador de Consultas assume que um número menor de linhas terá de ser processado para alcançar a meta de linhas.

Embora o objetivo de linha seja uma estratégia de otimização benéfica para certos padrões de consulta, se os dados não estiverem distribuídos uniformemente, podem ser digitalizadas mais páginas do que as estimadas, o que significa que o objetivo de linha se torna ineficiente. O feedback CE pode desativar a varredura de objetivos por linha e permitir uma busca quando esta ineficiência for detetada.

No plano de execução, não há um atributo específico para feedback de CE, mas há um atributo listado para a dica da Loja de Consultas. Procure que o QueryStoreStatementHintSource se torne CE feedback.

Considerações para o feedback da estimativa de cardinalidade (CE)

Para permitir feedback de estimativa de cardinalidade (CE), ative o nível de compatibilidade de base de dados 160 para a base de dados à qual está ligado ao executar a consulta. A Loja de Consultas deve estar ativada e em modo READ_WRITE para todas as bases de dados onde é utilizado feedback CE.
Para desativar o feedback CE ao nível da base de dados, use a CE_FEEDBACKconfiguração de âmbito da base de dados. Por exemplo, no banco de dados de usuários:
```
ALTER DATABASE SCOPED CONFIGURATION SET CE_FEEDBACK = OFF;
```
Para desativar o feedback CE ao nível da consulta, use a indicação DISABLE_CE_FEEDBACK da consulta.

A atividade de feedback CE é visível através dos query_feedback_analysis e query_feedback_validation XEvents.

As dicas definidas pelo feedback do CE podem ser acompanhadas usando a vista de catálogo sys.query_store_query_hints.

As informações de feedback podem ser rastreadas usando a vista de catálogo sys.query_store_plan_feedback.

Se uma consulta tiver um plano de consulta forçado através do Query Store, o feedback de CE não será utilizado para essa consulta.

Se uma consulta usar dicas de consulta codificadas fixamente ou estiver a usar dicas da Loja de Consultas definidas pelo utilizador, o feedback CE não é usado para essa consulta. Para mais informações, consulte Dicas de Consulta e Dicas de Consulta do Query Store.

A partir do SQL Server 2022 (16.x), quando o Query Store para réplicas secundárias está ativado, o feedback CE não é ciente das réplicas secundárias em grupos de disponibilidade. Atualmente, o feedback CE beneficia apenas réplicas primárias. Durante o failover, o feedback aplicado às réplicas primárias ou secundárias é perdido. A Loja de Consultas está disponível em réplicas do grupo de disponibilidade secundária a partir do SQL Server 2025 (17.x). Para obter mais informações, consulte Query Store para réplicas secundárias.

Persistência para feedback de estimativa de cardinalidade (CE)

Aplica-se a:Aplica-se a: SQL Server 2022 (16.x) e versões posteriores, Azure SQL Database, Azure SQL Managed Instance.

O feedback de estimativa de cardinalidade (CE) pode detetar cenários em que a otimização do objetivo de linhas deve ser mantida, mantendo esta alteração na Loja de Consultas sob a forma de uma dica na Loja de Consultas. A nova otimização é usada para execuções futuras da consulta. O feedback CE persiste noutros cenários para além dos padrões de consulta de otimização de objetivos por linhas, conforme detalhado nos cenários de feedback. O feedback do CE trata atualmente cenários de seletividade de predicados usados pelo modelo de correlação do CE, e cenários de predicados de junção que são tratados pelo modelo de contenção do CE.

Esta funcionalidade foi introduzida no SQL Server 2022 (16.x); no entanto, esta melhoria de desempenho está disponível para consultas que operem no nível de compatibilidade da base de dados 160 ou superior, ou com a indicação QUERY_OPTIMIZER_COMPATIBILITY_LEVEL_n de 160 ou superior, e quando o Query Store está ativado para a base de dados e em estado de "leitura-escrita".

Problemas conhecidos com o feedback da estimativa de cardinalidade (CE)

Questão	Data de descoberta	Situação	Data concluída
Desempenho lento do SQL Server após aplicar a Atualização Cumulativa 8 para SQL Server 2022 (16.x) sob certas condições. Pode encontrar uma utilização dramática da memória Cache Plan, juntamente com aumentos inesperados na utilização do CPU quando o feedback CE está ativado.	Dezembro de 2023	Resolvido	22 de abril de 2024 (12)

Detalhes dos problemas conhecidos

Desempenho lento do SQL Server após aplicar a Cumulative Update 8 para SQL Server 2022 sob certas condições

A partir da Atualização Cumulativa 8 do SQL Server 2022 (16.x), o SQL Server poderá apresentar aumentos inesperados na utilização de CPU e memória. Além disso, também pode ser observado um aumento nas esperas por RESOURCE_SEMAPHORE_QUERY_COMPILE. Pode também notar aumentos constantes no número de objetos do Cache de Plano em uso que se aproximam dos limites do Cache de Plano, e limpar manualmente o Cache de Plano com técnicas como ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE, DBCC FREESYSTEMCACHE, ou DBCC FREEPROCCACHE, não é eficaz. Este comportamento só foi observado por alguns clientes.

Esta questão não afeta todas as cargas de trabalho e depende do número de planos diferentes gerados, bem como do número de planos elegíveis para a funcionalidade de feedback do CE ser ativada. Enquanto o feedback CE analisa operadores de plano em busca de estimativas incorretas significativas do modelo, existe um cenário em que um plano referenciado pode ser desreferenciado durante esta fase de análise. Esta situação impede que o plano seja removido da memória usando o habitual algoritmo de Menos Recentemente Usado (LRU). O mecanismo LRU é uma das formas como o SQL Server aplica as políticas de despejo de planos. O SQL Server também remove planos da memória se o sistema estiver sob pressão de memória. Quando o SQL Server tenta remover os planos que foram desreferenciados de forma incorreta, não consegue remover esses planos da cache do plano, o que faz com que a cache continue a crescer. O crescimento da cache pode começar a causar compilações adicionais que, em última análise, consomem mais CPU e memória. Para mais informações, consulte Planos Internos do Cache.

Sintoma: O número de entradas de cache de planos em uso que estão marcadas como sujas de planos SQL ou de objeto aumenta ao longo do tempo para 50.000 ou mais. Se vir entradas na cache de planos que começam a aproximar-se deste nível, juntamente com aumentos inesperados na utilização de CPU, o seu sistema poderá estar a enfrentar este problema. Uma correção é fornecida com a Atualização Cumulativa 12 do SQL Server 2022 (16.x). Veja KB5033663.

Para monitorizar o número de entradas do cache plano que o seu sistema utiliza, os exemplos seguintes podem ser usados como uma vista pontual do número de entradas do cache plano existentes. Por exemplo, observar periodicamente o número de entradas do cache de planos que são marcadas como sujas ao longo do tempo é uma forma de monitorizar este fenómeno.

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;

Outro conjunto de consultas que também fornecem a mesma informação do exemplo anterior, permitindo ao mesmo tempo observar métricas adicionais de desempenho. As taxas de acerto do cache do plano diminuem, assim como o número de compilações em relação ao número de solicitações por segundo. As seguintes consultas podem ser usadas para monitorizar o seu sistema ao longo do tempo. Acompanhando a Razão de Acertos na Cache (quedas inesperadas), nos Objetos de Cache em uso (aumento da contagem para níveis próximos de 50.000 sem diminuir) e numa relação de Pedidos de Batch por sec inferior ao esperado em comparação com um aumento nas Compilações/sec.

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

Solução

Se o seu sistema continuar a apresentar os sintomas descritos anteriormente, após aplicar a Atualização Cumulativa 12 KB5033663, a funcionalidade de feedback CE pode ser desativada ao nível da base de dados.

Para recuperar a memória cache planeada ocupada por este problema, é necessário reiniciar a instância do SQL Server. Esta ação de reinício pode ser tomada após a desativação da funcionalidade de feedback do CE. Para desativar o feedback CE ao nível da base de dados, use a CE_FEEDBACKconfiguração de âmbito da base de dados. Por exemplo, no banco de dados de usuários:

ALTER DATABASE SCOPED CONFIGURATION SET CE_FEEDBACK = OFF;

Questões de feedback e reporte

Para feedback ou perguntas, envie um email CEFfeedback@microsoft.com

Comentários

Esta página foi útil?

Last updated on 2025-11-19