Recursos detalhados de processamento de consulta inteligente

Aplica-se a:SQL ServerBanco de Dados SQL do AzureInstância Gerenciada de SQL do AzureBanco de dados SQL no Microsoft Fabric

Este artigo contém descrições detalhadas de vários recursos de processamento inteligente de consulta (IQP), notas de versão e mais detalhes. A família de recursos IQP (processamento de consulta inteligente) inclui recursos de amplo impacto que melhoram o desempenho de cargas de trabalho existentes com esforço mínimo de implementação na adoção.

Você pode deixar as cargas de trabalho automaticamente qualificadas para o processamento de consulta inteligente habilitando o nível de compatibilidade do banco de dados aplicável. Você pode definir isso usando o Transact-SQL. Por exemplo, para definir o nível de compatibilidade de um banco de dados com o SQL Server 2022 (16.x):

ALTER DATABASE [WideWorldImportersDW]
    SET COMPATIBILITY_LEVEL = 160;

Veja mais informações sobre as alterações introduzidas com novas versões em:

• Novidades no SQL Server 2025
• Novidades do SQL Server 2022
• Novidades do SQL Server 2019
• Novidades no SQL Server 2017

Junções Adaptáveis em Modo de Lote

Aplica-se ao: SQL Server (a partir do SQL Server 2017 [14.x]) e banco de dados SQL do Azure

O recurso de Junções Adaptativas no modo em lote permite que a escolha de um método de Junção de Hash ou Junção de Loops Aninhados seja adiada até depois que a primeira entrada tiver sido examinada, usando um único plano armazenado em cache. O operador de Junção Adaptativa define um limite usado para decidir quando alternar para um plano de Nested Loops. Seu plano, portanto, pode mudar dinamicamente para uma estratégia de junção melhor durante a execução.

Para obter mais informações, incluindo como desabilitar junções adaptáveis sem alterar o nível de compatibilidade, confira Noções básicas sobre junções adaptáveis.

Execução intercalada para MSTVFs

Aplica-se ao: SQL Server (a partir do SQL Server 2017 [14.x]) e banco de dados SQL do Azure

Uma MSTVF (função com valor de tabela de várias instruções) é um tipo de função definida pelo usuário que pode aceitar parâmetros, executar várias instruções T-SQL e RETURN uma tabela.

A execução intercalada ajuda a resolver problemas de desempenho de cargas de trabalho que são devidos a estimativas de cardinalidade fixas associadas às MSTVFs. Com a execução intercalada, o número real de linhas da função é usado para tomar decisões mais bem informadas sobre o plano de consulta nas etapas posteriores.

As MSTVFs têm uma estimativa de cardinalidade fixa de 100 a partir do SQL Server 2014 (12.x) e 1 para versões anteriores do SQL Server.

A execução intercalada altera o limite unidirecional entre as fases de execução e de otimização para a execução de uma única consulta e permite que os planos se adaptem com base nas estimativas de cardinalidade revisadas. Durante a otimização, se o mecanismo de banco de dados encontrar um candidato para execução intercalada que usa funções com valor de tabela de várias instruções (MSTVFs), a otimização é pausada, a subárvore aplicável é executada, as estimativas de cardinalidade precisas são capturadas e, em seguida, a otimização é retomada para as operações subsequentes.

A imagem a seguir mostra uma saída de Live Query Statistics, um subconjunto de um plano de execução completo que mostra o impacto das estimativas fixas de cardinalidade de MSTVFs

Você pode ver o fluxo real de linhas em comparação com as linhas estimadas. Há três áreas notáveis do plano (o fluxo é da direita para esquerda):

• A varredura de tabela da MSTVF possui uma estimativa fixa de 100 linhas. Neste exemplo, no entanto, há 527.597 linhas passando por esta varredura da tabela MSTVF, como visto nas Estatísticas de Consulta ao Vivo por meio de 527597 de 100 reais versus estimadas — portanto, a estimativa fixa é significativamente imprecisa.
• Para a operação Nested Loops, presume-se que apenas 100 linhas sejam retornadas no lado externo da junção. Dado o alto número de linhas que realmente estão sendo retornadas pelo MSTVF, você provavelmente está melhor com um algoritmo de junção diferente completamente.
• Para a operação de correspondência de hash, observe o pequeno símbolo de aviso, que nesse caso está indicando um despejo no disco.

Compare o plano anterior com o plano real gerado com a execução intercalada habilitada:

• A verificação da tabela MSTVF agora reflete uma estimativa precisa de cardinalidade. Observe também a reordenação dessa verificação de tabela e das outras operações.
• E, em relação aos algoritmos de junção, passamos de uma operação de Loop Aninhado para uma operação de Hash Match, que é mais eficiente dado o grande número de linhas envolvidas.
• Além disso, observe que não temos mais avisos de spill, pois estamos concedendo mais memória com base na contagem real de linhas proveniente da varredura da tabela MSTVF.

Instruções aptas para execução intercalada

No momento, as instruções que fazem referência a MSTVFs na execução intercalada devem ser somente leitura e não podem fazer parte de uma operação de modificação de dados. Além disso, os MSTVFs não serão elegíveis para execução intercalada se não usarem constantes de runtime.

Benefícios de execução intercalada

Em geral, quanto maior a discrepância entre o número estimado e o número real de linhas, aliada ao número de operações subsequentes do plano, maior será o impacto no desempenho.

Em geral, a execução intercalada beneficia consultas em que:

• Há uma grande distorção entre o número estimado versus o número real de linhas para o conjunto de resultados intermediário (nesse caso, o MSTVF).

• E a consulta como um todo é sensível a alterações no tamanho do resultado intermediário. Isso normalmente acontece quando há uma árvore complexa acima dessa subárvore no plano de consulta.

  Um elemento básico SELECT * de um MSTVF não se beneficia de execução intercalada.

Sobrecarga da execução intercalada

A sobrecarga deve ser de mínima a nenhuma. As MSTVFs já estavam sendo materializadas antes da introdução da execução intercalada. No entanto, a diferença é que, agora, estamos permitindo a otimização adiada e, portanto, usando a estimativa de cardinalidade do conjunto de linhas materializadas. Assim como ocorre com qualquer plano sujeito a mudanças, alguns planos podem mudar de tal forma que, com uma cardinalidade melhor para a subárvore, obtenhamos um plano pior para a consulta como um todo. A mitigação pode incluir reverter o nível de compatibilidade ou usar o Repositório de Consultas para forçar a versão do plano sem regressão.

Execução intercalada e execuções consecutivas

Depois que um plano de execução intercalada é armazenado em cache, o plano com as estimativas revisadas na primeira execução é usado para as execuções consecutivas sem instanciar novamente a execução intercalada.

Acompanhe a atividade de execução intercalada

Você pode ver os atributos de uso no plano de execução de consulta real:

Você também pode controlar as ocorrências de execução intercalada por meio dos eventos estendidos a seguir:

Uma consulta deve ser executada a fim de permitir que a execução intercalada revise as estimativas de cardinalidade de MSTVF. No entanto, o plano de execução estimado ainda mostra quando há candidatos à execução intercalada por meio do atributo showplan ContainsInterleavedExecutionCandidates.

Armazenando em cache de execução intercalada

Se um plano for removido ou despejado do cache, ao ser executada a consulta, haverá uma nova compilação que usa a execução intercalada. Uma instrução que usa OPTION (RECOMPILE) gera um novo plano com execução intercalada e não o armazena em cache.

Execução intercalada e interoperabilidade com o Repositório de Consultas

Os planos que usam execução intercalada podem ser forçados. O plano é a versão que tem as estimativas de cardinalidade corrigidas com base na execução inicial.

Desabilitação da execução intercalada sem alterar o nível de compatibilidade

A execução intercalada pode ser desabilitada no escopo do banco de dados ou da instrução, mantendo o nível de compatibilidade do banco de dados como 140 e superior. Para desabilitar a execução intercalada para todas as execuções de consulta originadas do banco de dados, execute o seguinte dentro do contexto do banco de dados aplicável:

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

Quando habilitada, essa configuração é exibida como habilitada em sys.database_scoped_configurations. Para reativar a execução intercalada para todas as execuções de consultas originadas no banco de dados, execute o seguinte no contexto do banco de dados aplicável:

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

Também é possível desativar a execução intercalada para uma consulta específica especificando DISABLE_INTERLEAVED_EXECUTION_TVF como dica de consulta USE HINT. Por exemplo:

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

Um hint de consulta USE HINT tem precedência sobre uma configuração com escopo de banco de dados ou uma configuração de trace flag.

Expansão embutida de UDF escalar

Aplica-se ao: SQL Server (a partir do SQL Server 2019 [15.x]) e banco de dados SQL do Azure

O inlining da UDF escalar transforma automaticamente UDFs escalares em expressões relacionais. Insere-os na consulta SQL que faz a chamada. Essa transformação melhora o desempenho de cargas de trabalho que aproveitam as UDFs escalares. A expansão embutida de UDF escalar facilita a otimização baseada em custo das operações dentro das UDFs. Os resultados são eficientes, orientados para conjunto e paralelos, em vez de planos de execução ineficientes, iterativos e seriais. Esse recurso é habilitado por padrão no nível de compatibilidade do banco de dados 150 ou superior.

Para obter mais informações, consulte Embutimento de UDF escalar.

Compilação adiada de variável da tabela

Aplica-se ao: SQL Server (a partir do SQL Server 2019 [15.x]) e banco de dados SQL do Azure

A compilação adiada de variável da tabela melhora a qualidade do plano e o desempenho geral para consultas que fazem referência a variáveis de tabela. Durante a otimização e a compilação do plano inicial, esse recurso propaga estimativas de cardinalidade baseadas nas contagens reais de linhas das variáveis de tabela. Essas informações exatas de contagem de linhas são usadas para otimizar operações de plano downstream.

Com a compilação adiada de variável de tabela, a compilação de uma instrução que faz referência a uma variável de tabela é adiada até a primeira execução real da instrução. Esse comportamento de compilação adiada é idêntico ao das tabelas temporárias. Essa alteração resulta no uso de cardinalidade real em vez da estimativa original de uma linha.

Para habilitar a compilação adiada de variável da tabela, habilite o nível de compatibilidade do banco de dados 150 ou superior para o banco de dados ao qual você está conectado ao executar a consulta.

A compilação adiada de variável table não altera nenhuma outra característica das variáveis de tabela. Por exemplo, esse recurso não adiciona estatísticas de colunas às variáveis de tabela.

A compilação adiada de variável table não aumenta a frequência de recompilação. Em vez disso, ela alterna onde ocorre a compilação inicial. O plano em cache resultante é gerado com base na contagem inicial de linhas da variável de tabela de compilação adiada. O plano armazenado em cache é reutilizado por consultas consecutivas. Ele é reutilizado até que o plano seja descartado ou recompilado.

Uma contagem de linhas de variável de tabela usada para a compilação inicial de um plano pode representar um valor típico que é diferente de uma estimativa fixa de contagem de linhas. Se for diferente, as operações downstream se beneficiarão. O desempenho poderá não ser melhorado por esse recurso se a contagem de linha da variável de tabela variar consideravelmente entre as execuções.

Desabilitação da compilação adiada de variável de tabela sem alterar o nível de compatibilidade

Desabilite a compilação adiada de variável de tabela no escopo do banco de dados ou da instrução, mantendo o nível de compatibilidade do banco de dados em 150 ou superior. Para desabilitar a compilação adiada de variável table para todas as execuções de consulta originadas do banco de dados, execute o seguinte exemplo dentro do contexto do banco de dados aplicável:

ALTER DATABASE SCOPED CONFIGURATION SET DEFERRED_COMPILATION_TV = OFF;

Para habilitar novamente a compilação adiada de variável table para todas as execuções de consulta originadas do banco de dados, execute o seguinte exemplo dentro do contexto do banco de dados aplicável:

ALTER DATABASE SCOPED CONFIGURATION SET DEFERRED_COMPILATION_TV = ON;

Você também pode desativar a compilação diferida de variável de tabela para uma consulta específica definindo DISABLE_DEFERRED_COMPILATION_TV como uma hint de consulta USE HINT. Por exemplo:

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

Otimização do plano de sensibilidade a parâmetros

Aplica-se a: SQL Server 2022 (16.x) e versões posteriores Banco de Dados SQL do AzureInstância Gerenciada do Azure SQL

A otimização do PSP (plano de sensibilidade de parâmetro) faz parte do conjunto de recursos de processamento inteligente de consultas. Ela trata o cenário em que um só plano armazenado em cache de uma consulta parametrizada não é ideal para todos os valores de parâmetro de entrada possíveis. Isso é o que ocorre com distribuições de dados não uniformes.

• Para obter mais informações sobre a otimização de PSP, consulte Otimização de plano sensível a parâmetros.
• Para saber mais sobre a parametrização e sensibilidade de parâmetro, confira Sensibilidade de parâmetros e Reutilização de parâmetros e plano de execução.

Processamento de consulta aproximada

O processamento aproximado de consultas é uma nova família de funcionalidades. Ele agrega grandes conjuntos de dados nos quais a capacidade de resposta é mais importante do que a precisão absoluta. Um exemplo é calcular COUNT(DISTINCT()) em 10 bilhões de linhas, para exibição em um painel. Nesse caso, o que é importante não é a precisão absoluta, mas a capacidade de resposta que é essencial.

Contagem aproximada de valores distintos

Aplica-se ao: SQL Server (a partir do SQL Server 2019 [15.x]) e banco de dados SQL do Azure

A nova função de agregação APPROX_COUNT_DISTINCT retorna o número aproximado de valores não nulos exclusivos em um grupo.

Esse recurso está disponível a partir do SQL Server 2019 (15.x), para qualquer nível de compatibilidade.

Para obter mais informações, consulte APPROX_COUNT_DISTINCT.

Percentil aproximado

Aplica-se a: SQL Server (a partir do SQL Server 2022 [16.x]) e banco de dados SQL do Azure

Essas funções de agregação calculam percentis para um grande conjunto de dados com limites de erro aceitáveis baseados em ranking, para ajudar a tomar decisões rápidas usando funções aproximadas de agregação de percentis.

Para obter mais informações, consulte APPROX_PERCENTILE_DISC e APPROX_PERCENTILE_CONT

Modo em lote em rowstore

Aplica-se ao: SQL Server (a partir do SQL Server 2019 [15.x]) e banco de dados SQL do Azure

O modo de lote em rowstore permite a execução em modo de lote para cargas de trabalho analíticas sem exigir índices columnstore. Esse recurso oferece suporte à execução em modo de lote e a filtros de bitmap para heaps em disco e índices B-tree. O modo de lote no rowstore permite o suporte a todos os operadores existentes compatíveis com o modo de lote.

As consultas existentes que podem se beneficiar mais do modo de lote no rowstore incluem:

• Junções de hash entre tabelas grandes com armazenamento por linhas
• Consultas com GROUP BY sobre muitos valores distintos
• Funções de agregação comoSUM, , COUNT, MIN, MAXAVG
• Consultas de função de janela com OVER, PARTITION BY e ORDER BY, incluindo funções de agregação, ROW_NUMBER e RANK

Para obter mais informações sobre o desempenho da função de janela, consulte considerações de desempenho na referência da OVER cláusula.

Visão geral da execução em modo de lote

O SQL Server 2012 (11.x) introduziu um novo recurso para acelerar cargas de trabalho analíticas: índices columnstore. Os casos de uso e o desempenho de índices columnstore aumentaram a cada versão subsequente do SQL Server. Criar índices columnstore em tabelas pode melhorar o desempenho de cargas de trabalho analíticas. No entanto, há dois conjuntos de tecnologias relacionados mas distintos:

• Com os índices columnstore, as consultas analíticas acessam apenas os dados que elas precisam das colunas. A compactação de página no formato columnstore também é mais eficiente do que a dos índices rowstore tradicionais.
• Com o processamento em modo de lote, os operadores de consulta processam dados com mais eficiência. Eles processam um lote de linhas em vez de processar uma linha por vez. Diversos outros aprimoramentos de escalabilidade estão ligados ao processamento do modo de lote. Confira mais informações sobre o modo de lote em Modos de execução.

Os dois conjuntos de recursos funcionam juntos para melhorar o uso de CPU e E/S (entrada/saída):

• Ao usar índices columnstore, uma quantidade maior dos seus dados cabe na memória. Isso reduz a carga de trabalho de E/S.
• O processamento de modo de lote usa a CPU com mais eficiência.

As duas tecnologias tiram proveito um do outro sempre que possível. Por exemplo, agregações em modo de lote podem ser avaliadas como parte de uma varredura de índice columnstore. Os dados columnstore compactados também são processados muito mais eficientemente usando a codificação por comprimento de execução com junções em modo de lote e agregações em modo de lote.

No entanto, é importante entender que os dois recursos são independentes:

• Você pode obter planos no modo de linha que usam índices de armazenamento colunar.
• Você pode obter planos no modo de lote que usam somente índices rowstore.

Geralmente é possível obter os melhores resultados ao usar os dois recursos juntos. Antes do SQL Server 2019 (15.x), o otimizador de consulta do SQL Server considerava o processamento no modo em lotes só para consultas que envolvem pelo menos uma tabela com um índice columnstore.

Os índices columnstore podem não ser apropriados para alguns aplicativos. Um aplicativo pode usar algum outro recurso que não seja compatível com índices columnstore. Por exemplo, as modificações no local não são compatíveis com a compressão columnstore. Assim, os gatilhos não têm suporte em tabelas com índices columnstore clusterizados. Mais importante ainda, os índices columnstore adicionam sobrecarga às instruções DELETE e UPDATE.

Para algumas cargas de trabalho híbridas transacionais e analíticas, a sobrecarga de uma carga de trabalho transacional supera os benefícios proporcionados pelo uso de índices columnstore. Esses cenários podem se beneficiar de uma melhor utilização da CPU apenas com o processamento em modo de lote. É por isso que o recurso batch-mode-on-rowstore considera o modo de lote para todas as consultas independentemente de qual tipo de índice está envolvido.

Cargas de trabalho que podem se beneficiar do modo em lote no rowstore

As seguintes cargas de trabalho podem se beneficiar do modo de lote no rowstore:

• Uma parte significativa da carga de trabalho consiste em consultas analíticas. Em geral, essas consultas usam operadores como junções ou agregações que processam centenas de milhares de linhas ou mais.
• A carga de trabalho está associada à CPU. Se o gargalo for I/O, ainda é recomendável considerar um índice columnstore, sempre que possível.
• Criar um índice columnstore impõe sobrecarga excessiva ao componente transacional do workload. Ou, a criação de um índice columnstore não é viável porque seu aplicativo depende de um recurso que ainda não tem suporte com índices columnstore.

O que muda com o modo de lote no rowstore?

O modo em lotes no armazenamento de linhas requer que o banco de dados tenha nível de compatibilidade 150.

Mesmo que uma consulta não acesse tabelas com índices columnstore, o processador de consulta usa heurística para decidir se deseja considerar o modo de lote. A heurística consiste destas verificações:

1. Uma verificação inicial dos tamanhos de tabela, operadores usados e cardinalidades estimadas na consulta de entrada.
2. Pontos de verificação adicionais à medida que o otimizador descobre planos novos e mais baratos para a consulta. Se esses planos alternativos não usarem o modo de lote de forma significativa, o otimizador parará de explorar as alternativas de modo de lote.

Se o modo de lote em rowstore for usado, você verá o modo de execução real como o modo de lote no plano de consulta. O operador de varredura usa o modo em lote para heaps em disco e índices de árvore B. Essa varredura em modo em lote pode avaliar os filtros de bitmap em modo em lote. Você também poderá ver outros operadores de modo de lote no plano. Os exemplos são junções hash, agregações baseadas em hash, classificações, agregações de janela, filtros, concatenações e operadores escalares de computação.

Remarks

Os planos de consulta nem sempre usam o modo em lote. O otimizador de consulta pode decidir que o modo de lote não é útil para a consulta.

O espaço de pesquisa do otimizador de consulta está sendo alterado. Portanto, se você obtiver um plano em modo de linha, talvez não seja o mesmo plano obtido em um nível de compatibilidade mais baixo. E, se você obtiver um plano em modo de lote, ele pode não ser o mesmo plano que você obtém com um índice columnstore.

Os planos também podem mudar para consultas que combinam índices columnstore e rowstore devido à nova varredura de rowstore no modo de lote.

Há limitações atuais no novo modo de processamento em lote para varredura rowstore:

• Não entrará em ação para tabelas OLTP em memória nem para qualquer índice que não seja heap em disco ou árvore B.
• Ele também não entrará em ação se uma coluna LOB (objeto grande) for buscada ou filtrada. Essa limitação inclui conjuntos de colunas esparsas e colunas XML.

Há consultas para as quais o modo em lote não é usado, mesmo com índices columnstore. Os exemplos são consultas que envolvem cursores. Essas mesmas exclusões também se estendem ao modo em lote no rowstore.

Configurar o modo em lote no rowstore

A BATCH_MODE_ON_ROWSTOREconfiguração no escopo do banco de dados está ativada por padrão.

Você pode desabilitar o modo em lotes em rowstore sem alteração no nível de compatibilidade do banco de dados:

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

Você pode desativar o modo de lote no rowstore por meio da configuração no escopo do banco de dados. Mas você ainda pode substituir a configuração no nível da consulta usando a dica de consulta ALLOW_BATCH_MODE. O exemplo a seguir habilita o modo em lote no rowstore, mesmo quando o recurso está desabilitado por uma configuração no escopo do banco de dados:

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

Também é possível desativar o modo de lote no rowstore para uma consulta específica por meio da dica de consulta DISALLOW_BATCH_MODE. Consulte o seguinte exemplo:

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

Recursos de feedback sobre o processamento de consultas

Os recursos de feedback de processamento de consulta fazem parte da família de recursos de processamento de consulta inteligente.

O feedback de processamento de consulta são um processo pelo qual o processador de consultas no SQL Server, no banco de dados SQL do Azure e na Instância Gerenciada de SQL do Azure usa dados históricos sobre a execução de uma consulta para decidir se a consulta pode receber ajuda de uma ou mais alterações da forma como ela é compilada e executada. Os dados de desempenho são coletados no Repositório de Consultas, com várias sugestões para melhorar a execução da consulta. Se isso for bem-sucedido, gravamos essas modificações no disco, na memória e/ou no Repositório de Consultas para uso futuro. Se as sugestões não produzirem melhorias suficientes, elas serão descartadas, e a consulta continuará em execução sem esse feedback.

Para obter informações sobre quais recursos de feedback de processamento de consulta estão disponíveis em diferentes versões do SQL Server, ou no Banco de Dados SQL do Azure ou na Instância Gerenciada de SQL do Azure, confira Processamento inteligente de consultas em bancos de dados SQL ou os artigos a seguir para cada recurso de feedback.

Feedback de concessão de memória

O feedback de concessão de memória foi introduzido em etapas ao longo das últimas versões principais do SQL Server.

Feedback de concessão de memória no modo em lotes

Para obter informações sobre o feedback de concessão de memória no modo de lote, consulte Feedback de concessão de memória no modo de lote.

Comentários de concessão de memória do modo de linha

Para obter informações sobre feedback de concessão de memória no modo em linhas, visite Feedback de concessão de memória no modo em linhas.

Feedback de concessão de memória no modo de percentil e de persistência

Para obter informações sobre o feedback de concessão de memória nos modos de percentil e persistência, visite Feedback de concessão de memória nos modos de percentil e persistência.

Feedback sobre o grau de paralelismo (DOP)

Para obter informações sobre comentários do DOP, acesse Comentários do DOP (Grau de Paralelismo).

Feedback da CE (estimativa de cardinalidade)

Para obter informações sobre o feedback da CE, visite Feedback da CE (estimativa de cardinalidade).

Imposição de plano otimizado com Repositório de Consultas

Para ver informações sobre a imposição de plano otimizado com o Repositório de Consultas, visite Imposição de plano otimizado com o Repositório de Consultas.

Conteúdo relacionado

• Junções (SQL Server)
• Modos de execução
• Guia de arquitetura de processamento de consultas
• Referência de operadores lógicos e físicos do Showplan
• ALTER DATABASE SCOPED CONFIGURATION (Transact-SQL)
• Novidades no SQL Server 2017
• Novidades do SQL Server 2019
• Novidades do SQL Server 2022
• Demonstrar o processamento de consulta inteligente
• Dobragem de constantes e avaliação de expressões
• Demonstrações de processamento de consulta inteligente no GitHub
• Central de desempenho do Mecanismo de Banco de Dados do SQL Server e do Banco de Dados SQL do Azure
• Monitorar o desempenho usando o Repositório de Consultas
• Melhores práticas para monitorar cargas de trabalho com o Repositório de Consultas