Comparar planos de execução no SQL Server

O Administrador de Banco de Dados sempre se esforça para ajustar o desempenho da consulta do SQL Server. A primeira etapa para ajustar o desempenho da consulta é analisar o plano de execução de uma consulta. Sob algumas condições, o SQL Server Query Optimizer pode criar diferentes planos de execução. Neste ponto, gostaria de adicionar algumas notas sobre o SQL Server Query Optimizer. O SQL Server Query Optimizer é um otimizador baseado em custo que analisa os planos de execução e decide o plano de execução ideal para uma consulta. A palavra-chave significativa para o SQL Server Query Optimizer é um plano de execução ideal que não é necessariamente o melhor plano de execução. É por isso que, se o SQL Server Query Optimizer tentar descobrir o melhor plano de execução para cada consulta, levará mais tempo e prejudicará o desempenho do SQL Server Engine. No SQL Server 2016, a Microsoft adicionou uma nova capacidade ao SQL Server Management Studio, chamada Compare Showplan. Esse recurso nos permite comparar dois planos de execução diferentes. Ao mesmo tempo, podemos usar essa opção offline, o que significa que não precisamos conectar a instância do SQL Server. Imagine que você escreve uma consulta e essa consulta funciona bem no ambiente TEST, mas no PROD (ambiente de produção), ela funciona muito mal. Para lidar com esse problema, precisamos comparar os planos de execução. Antes desse recurso, costumávamos abrir dois SQL Server Management Studios e trazer planos de execução lado a lado, mas esse método era muito inconveniente.

Como comparar dois planos de execução?

Nesta demonstração, usaremos o banco de dados AdventureWorks e compararemos dois planos de execução que possuem diferentes versões do modelo de estimativa de cardinalidade e detectaremos essa diferença com o Compare Showplan.

Inicialmente, abriremos uma nova janela de consulta no SQL Server Management Studio e clicaremos em Incluir Plano de Execução Real e, em seguida, execute a seguinte consulta.

SELECT 
        soh.[SalesPersonID]
        ,p.[FirstName] + ' ' + COALESCE(p.[MiddleName], '') + ' ' + p.[LastName] AS [FullName]
        ,e.[JobTitle]
        ,st.[Name] AS [SalesTerritory]
        ,soh.[SubTotal]
        ,YEAR(DATEADD(m, 6, soh.[OrderDate])) AS [FiscalYear] 
    FROM [Sales].[SalesPerson] sp 
        INNER JOIN [Sales].[SalesOrderHeader] soh 
        ON sp.[BusinessEntityID] = soh.[SalesPersonID]
        INNER JOIN [Sales].[SalesTerritory] st 
        ON sp.[TerritoryID] = st.[TerritoryID] 
        INNER JOIN [HumanResources].[Employee] e 
        ON soh.[SalesPersonID] = e.[BusinessEntityID] 
		INNER JOIN [Person].[Person] p
		ON p.[BusinessEntityID] = sp.[BusinessEntityID]

Nesta etapa, salvaremos nosso primeiro plano de execução. Clique com o botão direito do mouse em qualquer lugar no plano de execução e clique em Salvar plano de execução como e salve o plano de execução como ExecutionPlan_CE140.sqlplan.

Agora vamos abrir uma nova aba de consulta no SQL Server Management Studio e executar a consulta abaixo. Nesta consulta, adicionaremos a dica de consulta FORCE_LEGACY_CARDINALITY_ESTIMATION no final da consulta, o que força o uso da versão mais antiga do modelo de estimativa de cardinalidade.
A tarefa de Estimativa de cardinalidade é prever quantas linhas nossa consulta retornará.

SELECT 
        soh.[SalesPersonID]
        ,p.[FirstName] + ' ' + COALESCE(p.[MiddleName], '') + ' ' + p.[LastName] AS [FullName]
        ,e.[JobTitle]
        ,st.[Name] AS [SalesTerritory]
        ,soh.[SubTotal]
        ,YEAR(DATEADD(m, 6, soh.[OrderDate])) AS [FiscalYear] 
    FROM [Sales].[SalesPerson] sp 
        INNER JOIN [Sales].[SalesOrderHeader] soh 
        ON sp.[BusinessEntityID] = soh.[SalesPersonID]
        INNER JOIN [Sales].[SalesTerritory] st 
        ON sp.[TerritoryID] = st.[TerritoryID] 
        INNER JOIN [HumanResources].[Employee] e 
        ON soh.[SalesPersonID] = e.[BusinessEntityID] 
INNER JOIN [Person].[Person] p
	ON p.[BusinessEntityID] = sp.[BusinessEntityID]
	OPTION (USE HINT ('FORCE_LEGACY_CARDINALITY_ESTIMATION'));

Clicaremos em Comparar plano de exibição e selecione o plano de execução anterior que foi salvo como ExecutionPlan_CE140.sqlplan.

A imagem a seguir ilustra a primeira tela do plano de comparação de execução do SQL Server e as áreas realçadas na cor rosa definem operações semelhantes.

Se clicarmos em qualquer operador na tela de plano de execução abaixo ou acima, o SQL Server Management Studio destaca outros operadores semelhantes. No lado direito do painel, você pode encontrar propriedades e detalhes de comparação de propriedades.

Nesta etapa, alteraremos as opções de Análise do ShowPlan e destacaremos o operador não correspondente. Na parte inferior da tela, podemos ver a Análise do plano de exibição painel. Se desmarcarmos Destacar operações semelhantes e selecione Destacar operadores que não correspondem a segmentos semelhantes O SQL Server Management Studio destaca o operador incomparável. Depois disso, clique em Selecionar operadores no plano de execução abaixo e acima no painel. O SQL Server Management Studio compara as propriedades dos operadores selecionados e coloca sinais de desigualdade nos valores não idênticos.

Se analisarmos essa tela com mais detalhes, a primeira coisa é a Versão do modelo de estimativa de cardinalidade diferença. A primeira versão da consulta é 70 e a segunda é 140. Essa diferença afeta o Número estimado de linhas . O principal motivo que causa o diferente Número estimado de linhas é uma versão diferente da estimativa de cardinalidade. Assim, a versão de estimativa de cardinalidade afeta diretamente as métricas estimadas da consulta. Para esta comparação de consulta, podemos concluir que a consulta cuja versão de estimativa de cardinalidade é 140 tem melhor desempenho porque o número estimado de linhas está próximo do Número real de linhas . Este caso pode ser esclarecido na tabela abaixo.

[ID da tabela=50 /]

Se quisermos ver os planos de execução lado a lado na mesma tela, podemos clicar em Alternar orientação do divisor .

Agora vamos fazer outra demonstração. Examinaremos a consulta abaixo e compararemos os planos de execução antes e depois da criação do índice.
Quando observamos o plano de execução da consulta abaixo, ele recomenda a criação de um índice não clusterizado.

SELECT [CarrierTrackingNumber] 
FROM [Sales].[SalesOrderDetail] WHERE [SalesOrderDetailID]=12

Vamos aplicar o índice recomendado e reexecutar a mesma consulta.

CREATE NONCLUSTERED INDEX Index_NC
ON [Sales].[SalesOrderDetail] ([SalesOrderDetailID])
GO
SELECT [CarrierTrackingNumber] 
FROM [Sales].[SalesOrderDetail] WHERE [SalesOrderDetailID]=12

Nesta última etapa, vamos comparar os planos de execução.

Na imagem acima, podemos obter várias informações sobre os planos de execução. Mas a principal diferença é a Operação Lógica campo. Uma delas é a Busca de índice e outro é Verificação de índice e essa diferenciação de operação leva a valores métricos estimados e reais diferentes. Por último, o operador Index Seek tem um desempenho melhor do que o operador Index Scan.

Conclusões

Como mencionamos no artigo, o recurso Compare Showplan oferece alguns benefícios para o Desenvolvedor ou Administrador de Banco de Dados. Algumas delas podem ser contadas como:

Simples para comparar a diferença de dois planos de execução.
Simples para detectar problemas de desempenho de consulta em diferentes versões do SQL Server.
Simples para detectar problemas de desempenho de consulta em diferentes ambientes.
Simplesmente esclarece as alterações do plano de execução antes e depois da criação do índice.

Referências

Estimativa de cardinalidade (SQL Server)
Guia de arquitetura de processamento de consultas