Partilhar via

Recursos inteligentes de processamento de consultas em detalhes

Aplica-se a:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceBase de dados SQL no Microsoft Fabric

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

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

ALTER DATABASE [WideWorldImportersDW]
    SET COMPATIBILITY_LEVEL = 160;

Para obter mais informações sobre as alterações introduzidas com as novas versões, consulte:

Associações adaptáveis em modo batch

Aplica-se a: SQL Server (a partir do SQL Server 2017 (14.x)), Banco de Dados SQL do Azure

O recurso Adaptive Joins do modo de lote permite que a escolha de um método Hash Join ou Nested Loops Join seja adiada até depois da primeira entrada ter sido verificada, utilizando um único plano em cache. O operador Adaptive Join define um limite que é utilizado para decidir quando alternar para um plano de Nested Loops. Seu plano pode, portanto, mudar dinamicamente para uma melhor estratégia de junção durante a execução.

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

Execução intercalada para MSTVFs

Aplica-se a: SQL Server (a partir do SQL Server 2017 (14.x)), Banco de Dados SQL do Azure

Uma função com valor de tabela de várias instruções (MSTVF) é 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 os problemas de desempenho da carga de trabalho que são devidos a estimativas de cardinalidade fixa associadas a MSTVFs. Com a execução intercalada, as contagens de linhas reais da função são usadas para tomar decisões mais informadas sobre o plano de consulta nas etapas subsequentes.

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 otimização e execução para uma execução de consulta única e permite que os planos se adaptem com base nas estimativas de cardinalidade revisadas. Durante a otimização, se o motor da base de dados encontrar um candidato para execução intercalada que utilize funções de tabela multi-instruções (MSTVFs), a otimização é suspensa, executa a subárvore aplicável, captura estimativas de cardinalidade precisas, e depois continua a otimização para operações posteriores.

A imagem seguinte apresenta uma saída das Estatísticas de Consultas Ativas, que são um subconjunto do plano de execução geral e mostram o impacto das estimativas de cardinalidade fixa de Funções de Valor de Tabela Multidefinidas (MSTVFs).

Você pode ver o fluxo de linha real versus as linhas estimadas. Há três áreas notáveis do plano (o fluxo é da direita para a esquerda):

  • O MSTVF Table Scan tem uma estimativa fixa de 100 linhas. Para este exemplo, no entanto, há 527.597 linhas fluindo através desta verificação de tabela MSTVF, como visto em Live Query Statistics através do 527597 de 100 reais estimados - portanto, a estimativa fixa é significativamente distorcida.
  • Para a operação Nested Loops, espera-se que apenas 100 linhas sejam retornadas pelo lado externo da junção. Dado o elevado número de linhas que são realmente devolvidas pelo MSTVF, provavelmente é melhor usar um algoritmo de junção completamente diferente.
  • Para a operação Hash Match, observe o pequeno símbolo de aviso, que neste caso está indicando um derramamento para o disco.

Diagrama do fluxo de linhas de um plano de execução versus linhas estimadas.

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

Diagrama de um plano de execução entrelaçado.

  • A varredura da tabela MSTVF reflete agora uma estimativa precisa de cardinalidade. Observe também a reordenação desta análise de tabela e de outras operações.
  • E em relação aos algoritmos de junção, mudámos de uma operação de Loop Aninhado para uma operação de Hash Match em vez disso, o que é mais adequado dado o grande número de linhas envolvidas.
  • Note que já não temos avisos de sobrecarga de memória, à medida que concedemos mais memória com base na verdadeira contagem de linhas que provém da varredura da tabela MSTVF.

Declarações elegíveis para execução intercalada

As instruções de referência MSTVF na execução intercalada devem ser necessariamente de leitura e não podem fazer parte de uma operação de modificação de dados. Além disso, os MSTVFs não são elegíveis para execução intercalada se não usarem constantes de execução.

Benefícios da execução intercalada

Em geral, quanto maior o desvio entre o número estimado e o número real de linhas, juntamente com o número de operações subsequentes do plano, maior o impacto no desempenho.

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

  • Existe um grande descompasso entre o número estimado e o número real de linhas para o conjunto de resultados intermédios (neste caso, o MSTVF).

  • E a consulta geral é sensível a uma alteração no tamanho do resultado intermediário. Isto normalmente acontece quando há uma árvore complexa acima dessa subárvore no plano de consulta.

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

Sobrecarga de execução intercalada

A sobrecarga deve ser mínima a nenhuma. MSTVFs já estavam a ser materializados antes da introdução da execução intercalada; no entanto, a diferença é que agora permitimos a otimização adiada e usamos a estimativa de cardinalidade do conjunto de linhas materializado. Como em qualquer plano que envolva mudanças, alguns planos podem mudar de tal forma que, com uma melhor cardinalidade da subárvore, obtemos um plano pior para a consulta em geral. A atenuação pode incluir a reversão do nível de compatibilidade ou o uso do Repositório de Consultas para forçar a versão não regressão do plano.

Execução intercalada e execuções consecutivas

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

Monitorize a atividade de execução intercalada

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

Atributo do Plano de Execução Description
ContainsInterleavedExecutionCandidates Aplica-se ao nó QueryPlan. Quando verdadeiro, significa que o plano contém candidatos de execução intercalados.
IsInterleavedExecuted Atributo do elemento RuntimeInformation dentro do RelOp para o nó TVF. Quando verdadeiro, indica que a operação foi materializada como parte de uma operação de execução intercalada.

Você também pode rastrear ocorrências de execução intercaladas por meio dos seguintes eventos estendidos:

XEvent Description
interleaved_exec_status Este evento é acionado quando a execução intercalada está ocorrendo.
interleaved_exec_stats_update Este evento descreve as estimativas de cardinalidade atualizadas pela execução intercalada.
Interleaved_exec_disabled_reason Este evento é desencadeado quando uma consulta com um possível candidato para execução intercalada não chega a ser executada de forma intercalada.

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

Cache para execução entrelaçada

Se um plano for apagado ou despejado da cache, na execução da consulta há uma compilação nova que usa execução intercalada. Uma instrução usando OPTION (RECOMPILE) cria um novo plano utilizando execução intercalada e não o armazena em cache.

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

Planos usando execução intercalada podem ser forçados. O plano é a versão que corrigiu as estimativas de cardinalidade com base na execução inicial.

Desative a execução intercalada sem alterar o nível de compatibilidade

A execução intercalada pode ser desativada no âmbito da base de dados ou da instrução, mantendo ainda a compatibilidade da base de dados no nível 140 e superior. Para desabilitar a execução intercalada para todas as execuções de consulta originadas do 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 = 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 aparece como habilitada no sys.database_scoped_configurations. Para reativar a execução intercalada para todas as execuções de consulta originadas do 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;

Você também pode desativar a execução entrelaçada para uma consulta específica, indicando DISABLE_INTERLEAVED_EXECUTION_TVF como uma USE HINT dica de consulta. 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'));

Uma dica USE HINT tem precedência sobre uma configuração de escopo de banco de dados ou definição de sinalizador de rastreamento.

Inlining de UDF escalar

Aplica-se a: SQL Server (a partir do SQL Server 2019 (15.x)), Banco de Dados SQL do Azure

O inlining UDF escalar transforma automaticamente UDFs escalares em expressões relacionais. Ele os incorpora na consulta SQL de chamada. Essa transformação melhora o desempenho de cargas de trabalho que aproveitam UDFs escalares. O inlining UDF escalar facilita a otimização baseada em custos das operações dentro de UDFs. Os resultados são eficientes, orientados para conjuntos 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 Scalar UDF inlining.

Compilação diferida da variável de tabela

Aplica-se a: SQL Server (a partir do SQL Server 2019 (15.x)), Banco de Dados SQL do Azure

A compilação adiada de variáveis de 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 inicial do plano, esse recurso propaga estimativas de cardinalidade baseadas em contagens de linhas de variáveis da tabela real. Esta informação exata sobre a contagem de linhas é então usada para otimizar as operações do plano subsequente.

Com a compilação diferida da variável table, a compilação de uma instrução que faz referência a uma variável table é adiada até a primeira execução real da instrução. Esse comportamento de compilação adiada é idêntico ao comportamento de tabelas temporárias. Esta alteração resulta na utilização da cardinalidade real em vez da estimativa original de uma única linha.

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

A compilação diferida de variáveis de tabela não altera nenhuma outra característica das variáveis de tabela. Por exemplo, esse recurso não adiciona estatísticas de coluna a variáveis de tabela.

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

A contagem de linhas de uma variável de tabela usada para a compilação do plano inicial representa um valor típico que pode ser diferente de uma estimativa fixa de contagem de linhas. As operações a jusante beneficiam-se caso seja diferente. O desempenho pode não ser melhorado por esse recurso se a contagem de linhas da variável da tabela variar significativamente entre as execuções.

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

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

ALTER DATABASE SCOPED CONFIGURATION SET DEFERRED_COMPILATION_TV = OFF;

Para reativar a compilação adiada da variável de tabela para todas as execuções de consulta originadas do banco de dados, execute o seguinte exemplo no contexto do banco de dados aplicável:

ALTER DATABASE SCOPED CONFIGURATION SET DEFERRED_COMPILATION_TV = ON;

Você também pode desativar a compilação adiada da variável de tabela para uma consulta específica atribuindo DISABLE_DEFERRED_COMPILATION_TV como uma dica USE HINT numa consulta. 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 Azure SQL DatabaseAzure SQL Managed Instance

A otimização do Plano de Sensibilidade a Parâmetros (PSP) faz parte da família de recursos de processamento inteligente de consultas. Ele aborda o cenário em que um único plano armazenado em cache para uma consulta parametrizada não é ideal para todos os possíveis valores de parâmetros de entrada. É o caso das distribuições de dados não uniformes.

Processamento aproximado de consultas

O processamento aproximado de consultas é uma nova família de recursos. Agrega em grandes conjuntos de dados, onde a responsividade é mais crítica do que a precisão absoluta. Um exemplo é o cálculo de um COUNT(DISTINCT()) em 10 bilhões de linhas, para exibição em um painel. Neste caso, a precisão absoluta não é importante, mas a capacidade de resposta é fundamental.

Contagem aproximada distinta

Aplica-se a: SQL Server (a partir do SQL Server 2019 (15.x)), 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), independentemente do nível de compatibilidade.

Para mais informações, consulte APPROX_COUNT_DISTINCT.

Percentil aproximado

Aplica-se a: SQL Server (a partir do SQL Server 2022 (16.x)), Banco de Dados SQL do Azure

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

Para mais informações, consulte APPROX_PERCENTILE_DISC e APPROX_PERCENTILE_CONT

Modo em lote no armazenamento em linhas

Aplica-se a: SQL Server (a partir do SQL Server 2019 (15.x)), Banco de Dados SQL do Azure

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

Note

A documentação usa o termo árvore B geralmente em referência a índices. Em índices de armazenamento em linha, o Mecanismo de Base de Dados implementa uma árvore B+. Isso não se aplica a índices de armazenamento em colunas ou a índices em tabelas com otimização de memória. Para obter mais informações, consulte o guia de arquitetura e design de índices do SQL Server e Azure SQL .

Visão geral da execução do 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 dos índices columnstore aumentaram em cada versão subsequente do SQL Server. A criação de índices columnstore em tabelas pode melhorar o desempenho de cargas de trabalho analíticas. No entanto, existem dois conjuntos de tecnologias relacionados, mas distintos:

  • Com os índices columnstore , as consultas analíticas acessam apenas os dados nas colunas de que precisam. A compressão de páginas no formato columnstore é também mais eficaz do que a compressão em índices tradicionais de rowstore.
  • Com o processamento em modo batch , os operadores de consulta processam dados de forma mais eficiente. Trabalham num conjunto de linhas em vez de uma linha de cada vez. Muitas outras melhorias de escalabilidade estão ligadas ao processamento em modo batch. Para obter mais informações sobre o modo de lote , consulte Modos de execução.

Os dois conjuntos de recursos trabalham juntos para melhorar a entrada/saída (E/S) e a utilização da CPU:

  • Os índices de armazenamento em colunas permitem que mais dados caibam na memória. Isso reduz a carga de trabalho de E/S.
  • O processamento em modo batch usa a CPU de forma mais eficiente.

As duas tecnologias tiram partido uma da outra sempre que possível. Por exemplo, as agregações em modo de lote podem ser avaliadas como parte de uma verificação de índice columnstore. Além disso, os dados columnstore compactados são processados de maneira muito mais eficiente usando a codificação de comprimento de execução, especialmente com junções e agregações em modo de lote.

É importante perceber, no entanto, que as duas características são independentes:

  • Você pode obter planos em modo de linha que usam índices de armazenamento em colunas.
  • Pode obter planos no modo de lote que utilizam apenas índices de linha.

Você geralmente obtém os melhores resultados quando usa os dois recursos juntos. Antes do SQL Server 2019 (15.x), o otimizador de consulta do SQL Server considerava o processamento em modo de lote apenas para consultas que envolvessem pelo menos uma tabela com um índice columnstore.

Os índices Columnstore podem não ser apropriados para alguns aplicativos. Uma aplicação pode usar algum outro recurso que não é suportado por índices columnstore. Por exemplo, as modificações no local não são compatíveis com compressão em columnstore. Portanto, não há suporte para gatilhos em tabelas com índices columnstore clusterizados. Mais importante, os índices columnstore adicionam sobrecarga para instruções DELETE e UPDATE .

Para algumas cargas de trabalho híbridas de transações e análises, a sobrecarga de uma carga de trabalho transacional supera os benefícios obtidos com o uso de índices de armazenamento em colunas. Esses cenários podem se beneficiar do uso aprimorado da CPU empregando apenas o processamento em modo de lote. É por isso que o recurso batch-mode-on-rowstore considera o modo batch para todas as consultas, independentemente do tipo de índices envolvidos.

Cargas de trabalho que podem beneficiar-se do modo de lote no armazenamento por linhas

As seguintes cargas de trabalho podem beneficiar-se do modo em lote no armazenamento em linha:

  • Uma parte significativa da carga de trabalho consiste em consultas analíticas. Normalmente, essas consultas usam operadores como junções ou agregações que processam centenas de milhares de linhas ou mais.
  • A carga de trabalho está vinculada à CPU. Se o estrangulamento for I/O, é ainda recomendável que consideres um índice na columnstore, sempre que possível.
  • Criar um índice columnstore gera uma sobrecarga excessiva na parte transacional da sua carga de trabalho. Ou então, criar um índice no columnstore não é viável porque a sua aplicação depende de uma funcionalidade que ainda não é suportada pelos índices do columnstore.

Note

O modo de lote no armazenamento de linhas ajuda apenas ao reduzir o consumo de CPU. Se o teu gargalo estiver relacionado com I/O e os dados ainda não estiverem armazenados em cache ("cold cache"), o modo batch na rowstore não melhora o tempo decorrido da consulta. De forma semelhante, se não houver memória suficiente na máquina para armazenar todos os dados em cache, é improvável uma melhoria de desempenho.

O que muda com o modo de lote no rowstore?

O modo de lote no armazenamento de linhas requer que o banco de dados esteja no nível de compatibilidade 150.

Mesmo que uma consulta não aceda a quaisquer tabelas com índices de columnstore, o processador de consultas usa heurísticas para decidir se considera o modo de lote. A heurística consiste nestas verificações:

  1. Uma verificação inicial de tamanhos de tabela, operadores usados e cardinalidades estimadas na consulta de entrada.
  2. Pontos de verificação adicionais, à medida que o otimizador descobre novos planos mais baratos para a consulta. Se esses planos alternativos não fizerem uso significativo do modo de lote, o otimizador para de explorar alternativas de modo de lote.

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

Remarks

Os planos de consulta nem sempre usam o modo de lote. O Otimizador de Consultas pode decidir que o modo em lote não é benéfico para a consulta.

O espaço de pesquisa do Otimizador de Consultas está mudando. Portanto, se você obtiver um plano de modo de linha, ele pode não ser o mesmo que o plano obtido em um nível de compatibilidade mais baixo. E se tu obtiveres um plano em modo de lote, ele pode não ser o mesmo que o plano que obtens com um índice do columnstore.

Os planos também podem mudar para consultas que misturam índices columnstore e rowstore devido à nova varredura rowstore em modo batch.

Há limitações atuais para o novo modo de lote na varredura de rowstore:

  • Não será ativado para tabelas OLTP na memória ou para qualquer índice que não seja heaps em disco e árvores B.
  • Ele também não será ativado se uma coluna de objeto grande (LOB) for obtida ou filtrada. Essa limitação inclui conjuntos de colunas esparsas e colunas XML.

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

Configurar o modo de lote no armazenamento de linhas

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

Você pode desativar o modo de lote no Rowstore sem alterar o 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 armazenamento de linha por meio da configuração do escopo do banco de dados. Mas ainda pode substituir a configuração ao nível da consulta usando o indicador de consulta ALLOW_BATCH_MODE. O exemplo a seguir habilita o modo em lote no armazenamento em linha, mesmo quando o recurso está desativado na configuração de 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'));

Você também pode desativar o modo de lote no rowstore para uma consulta específica usando a indicação de DISALLOW_BATCH_MODE consulta. Veja 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'));

Funcionalidades de feedback no processamento de consultas

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

O feedback de processamento de consultas é um processo pelo qual o processador de consultas no SQL Server, no Banco de Dados SQL do Azure e na Instância Gerenciada 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 na maneira como é 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 forem bem-sucedidas, persistiremos 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á a ser executada 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 SQL do Azure, consulte Processamento inteligente de consultas em bancos de dados SQL ou os seguintes artigos para cada recurso de feedback.

Comentários sobre a concessão de espaço de memória

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

Feedback de concessão de memória em modo batch

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

A memória do modo de linha concede feedback

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

O percentil e a memória do modo de persistência concedem feedback

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

Feedback sobre o grau de paralelismo (DOP)

Para obter informações sobre comentários DOP, visite Comentários sobre o grau de paralelismo (DOP).

Feedback sobre a estimativa de cardinalidade (CE)

Para obter informações sobre o feedback de CE, visite Comentários de estimativa de cardinalidade (CE).

Força de plano otimizada com o Query Store

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

Conteúdo relacionado

  • Last updated on