Compartilhar via

Recursos detalhados de processamento de consulta inteligente

  • Artigo

Aplica-se a: SQL Server Banco de Dados SQL do Azure Instância Gerenciada de SQL do Azure Banco de Dados SQL no Microsoft Fabric

Este artigo contém descrições detalhadas de vários IQP (recurso de processamento de consulta inteligente), 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:

Junções Adaptáveis de 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 Adaptáveis de modo de lote permite que a escolha de um método de Junção hash ou de Junção de loops aninhados seja adiada até depois que a primeira entrada for verificada, usando um único plano em cache. O operador de Junção Adaptável define um limite que é usado para decidir quando mudar para um plano de Loops aninhados. Seu plano, portanto, pode alternar 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 com problemas de desempenho da carga de trabalho causado por estimativas de cardinalidade fixas associadas às MSTVFs. Com a execução intercalada, as contagens de linha reais da função são usadas para tornar decisões de plano de consulta downstream mais embasadas.

As MSTVFs têm uma estimativa de cardinalidade fixa de 100 começando com SQL Server 2014 (12.x) e de 1 para versões anteriores 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 uma candidata para execução intercalada que use MSTVFs (funções com valor de tabela de várias instruções), a otimização será pausada, executará a subárvore aplicável, capturará as estimativas de cardinalidade precisas e retomará a otimização para operações downstream.

A imagem a seguir ilustra uma saída de Estatísticas de consulta dinâmica, um subconjunto de um plano de execução geral que mostra o impacto das estimativas de cardinalidade fixas de MSTVFs

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

  • A verificação de tabela de MSTVF tem uma estimativa fixa de 100 linhas. Neste exemplo, no entanto, há 527.597 linhas que passam por essa Verificação de tabela de MSTVF, conforme visto nas Estatísticas de consulta dinâmicas por meio de 527597 de 100 reais das estimadas, portanto a estimativa fixa é significativamente distorcida.
  • Para a operação de loops aninhados, apenas 100 linhas são consideradas retornadas pelo lado externo da junção. Devido ao grande número de linhas que realmente estão sendo retornadas pelo MSTVF, provavelmente melhor usar um algoritmo de junção completamente diferente.
  • 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.

Gráfico de um fluxo de linha do plano de execução versus linhas estimadas.

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

Gráfico do plano de execução intercalado.

  • Observe que a verificação de tabela de MSTVF agora reflete uma estimativa de cardinalidade precisa. 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, mudamos de uma operação de loops aninhados para uma operação de correspondência de hash, que é mais ideal devido ao grande número de linhas envolvidas.
  • Além disso, observe que não há mais avisos de despejo necessários, pois estamos concedendo mais memória com base na contagem verdadeira de linhas que passam da verificação da tabela de MSTVF.

Instruções qualificadas para execução intercalada

A MSTVF que referencia instruções em execução intercalada deve estar somente leitura e não fazer parte de uma operação de modificação de dados. Além disso, MSTVFs não serão qualificados para execução intercalada se não usarem constantes em runtime.

Benefícios de execução intercalada

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

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

  • Há uma grande distorção entre o número de linhas estimado e real para o conjunto de resultados intermediário (neste caso, o MSTVF).
  • E a consulta geral é sensível a uma alteração no tamanho do resultado intermediário. Isso geralmente acontece quando há uma árvore complexa acima dessa subárvore no plano de consulta. Um simples SELECT * de uma MSTVF não se beneficiará da 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 acontece com qualquer plano que afeta as alterações, alguns planos podem ser alterados de modo que com uma cardinalidade melhor da subárvore podemos obter um plano pior para a consulta geral. A mitigaçã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 retornada do plano.

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.

Controle da atividade de execução intercalada

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

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

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

XEvent Descrição
interleaved_exec_status Esse evento é disparado quando a execução intercalada está ocorrendo.
interleaved_exec_stats_update Esse evento descreve as estimativas de cardinalidade atualizadas por execução intercalada.
Interleaved_exec_disabled_reason Esse evento é disparado quando uma consulta com uma possível candidata para execução intercalada, na verdade, não obtém a execução intercalada.

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

Armazenando em cache de execução intercalada

Se um plano é limpo ou removido do cache, após a execução da consulta há uma nova compilação que usa a execução intercalada. Uma instrução que usa OPTION (RECOMPILE) cria um plano usando a execução intercalada e não a armazena em cache.

Execução intercalada e interoperabilidade do 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 reabilitar 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 = OFF;

-- Starting with SQL Server 2019, and in Azure SQL Database
ALTER DATABASE SCOPED CONFIGURATION SET INTERLEAVED_EXECUTION_TVF = ON;

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

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

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

Embutimento 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. Ele as incorpora à chamada da consulta SQL. Essa transformação melhora o desempenho de cargas de trabalho que aproveitam as UDFs escalares. O inlining da UDF escalar facilita a otimização baseada em custo de operações 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 saber mais, confira Scalar UDF Inlining (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 compilação do plano inicial, esse recurso propaga estimativas de cardinalidade com base nas contagens reais de linha de variável de tabela. Essas informações de contagem de linha precisas serão usadas para otimizar operações de plano de 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 as estatísticas de coluna às variáveis table.

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 armazenado em cache resultante é gerado com base na contagem da linha de variável table de compilação adiada inicial. O plano armazenado em cache é reutilizado por consultas consecutivas. Ele é reutilizado até que o plano seja removido ou recompilado.

A contagem de linha de variável de tabela que é usada para a compilação de plano inicial representa um valor típico que pode ser diferente de uma estimativa de contagem de linha fixa. Se ele for diferente, as operações downstream serão beneficiadas. 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

Desabilitar a compilação adiada de variável table no escopo do banco de dados ou da instrução, mantendo o nível de compatibilidade do banco de dados como 150 e 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 desabilitar a compilação adiada de variável table em uma consulta específica atribuindo DISABLE_DEFERRED_COMPILATION_TV como uma dica 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 de parâmetro

Aplica-se a: SQL Server 2022 (16.x) Banco de Dados SQL do Azure Instância Gerenciada de SQL do Azure

A otimização do PSP (plano de sensibilidade de parâmetro) faz parte da família de recursos de processamento de consulta inteligente. Ela aborda 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.

Processamento de consulta aproximada

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

Distinção de contagem aproximada

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 saber mais, confira APPROX_COUNT_DISTINCT (Transact-SQL).

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 agregadas calculam rapidamente percentis para um conjunto de dados grande com limites de erro aceitáveis baseados em classificação que ajudam a acelerar decisões usando funções de agregação de percentil aproximadas.

Para obter mais informações, confira APPROX_PERCENTILE_DISC (Transact-SQL) e APPROX_PERCENTILE_CONT (Transact-SQL)

Modo de Lote no 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 que a execução em modo de lote para cargas de trabalho analíticas sem a necessidade de índices columnstore. Esse recurso dá suporte a filtros de bitmap e à execução do modo de lote para em disco heaps e índices de árvore B. O modo de lote em rowstore habilita o suporte para todos os operadores habilitados para o modo de lote existente.

Observação

A documentação usa o termo árvore B geralmente em referência a índices. Em índices de rowstore, o Database Engine implementa uma árvore B+. Isso não se aplica a índices columnstore ou índice em tabelas com otimização de memória. Para obter mais informações, confira o Guia de arquitetura e design do índice do SQL Server e SQL do Azure.

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 funcionam em um lote de linhas em vez de 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, mais dos seus dados se encaixam 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 de modo de lote podem ser avaliadas como parte de uma verificação de índice columnstore. Os dados de columnstore compactados também são processados usando a codificação de tamanho de execução com muito mais eficiência com junções e agregações de modos de lotes.

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

  • Você pode obter planos de modo de linha que usam índices columnstore.
  • Você pode obter planos de modo de linha 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. Pode ser que o aplicativo use outro recurso que não tenha suporte com índices columnstore. Por exemplo, as modificações no local não são compatíveis com a compactação de columnstore. Assim, os gatilhos não têm suporte em tabelas com índices columnstore clusterizados. E, mais importante, índices columnstore adicionam uma sobrecarga para as instruções DELETE e UPDATE.

Para algumas cargas de trabalho transacionais analíticas híbridas, a sobrecarga de uma carga de trabalho transacional supera os benefícios obtidos do uso de índices columnstore. Esses cenários podem se beneficiar do uso aprimorado da CPU empregando o processamento do modo de lote sozinho. É 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 com o modo de 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 em E/S, ainda será recomendável que você considere um índice columnstore, se possível.
  • Criar um índice columnstore adiciona muita sobrecarga à parte transacional da carga de trabalho. 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.

Observação

O modo de lote em rowstore só pode ajudar a reduzir o consumo de CPU. Se o gargalo for relacionado à E/S e os dados ainda não estiverem armazenados em cache (cache "frio"), o modo de lote em rowstore não vai melhorar o tempo decorrido da consulta. Da mesma forma, se não houver memória o bastante no computador para armazenar em cache todos os dados, será improvável que ocorra uma melhoria de desempenho.

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 nenhuma tabela com índices columnstore, o processador de consultas usa a heurística para decidir se deve 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 verificação usa o modo de lote em heaps em discos e índices de árvore B. Essa verificação do modo de lote pode avaliar os filtros de bitmap do modo de 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.

Comentários

Planos de consulta nem sempre usam o modo de 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ê receber um plano de modo de linha, poderia não ser o mesmo que o plano que você obtém em um nível de compatibilidade mais baixo. E se você receber um plano de modo de lote, poderia não ser o mesmo que o plano que você obtém com um índice columnstore.

Os planos também podem alterar as consultas que combinam os índices columnstore e rowstore devido à verificação de rowstore do novo modo de lote.

Existem limitações atuais para o novo modo de lote na verificação de rowstore:

  • Ele não será iniciado para tabelas OLTP na memória nem para índices diferentes de heaps em disco e árvores B.
  • Ele também não será iniciado ao buscar ou filtrar uma coluna LOB (de objeto grande). Essa limitação inclui conjuntos de colunas esparsas e colunas XML.

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

Configurar o modo de lote no rowstore

A configuração de banco de dados no escopo BATCH_MODE_ON_ROWSTORE 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 desabilitar o modo em lotes em rowstore por meio de configuração do 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 de lote no rowstore, mesmo com o recurso desabilitado por meio de configuração com 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 desabilitar o modo em lotes em rowstore para uma consulta específica usando a 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 de processamento de consulta

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 for bem-sucedido, persistimos 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.

Comentários de concessão de memória

O feedback de concessão de memória foi introduzido em sessões nos últimos lançamentos principais do SQL Server.

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

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

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 ver informações sobre o feedback de concessão de memória de percentil e modo de persistência, visite Feedback de concessão de memória no modo de percentil e de persistência.

Comentários de DOP (grau de paralelismo)

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