É sempre recomendado ao escrever consultas ou código de banco de dados SQL Server (procedimentos e exibições) tomar conhecimento do plano de execução. Há várias razões para isso. Em primeiro lugar – o otimizador pode estar escolhendo um plano que você não está esperando. Por exemplo, a varredura de índice em uma tabela grande antes de fazer a correspondência com uma tabela menor. Em segundo lugar, deve-se levar em consideração como essa consulta será executada nos próximos meses ou anos se as consultas estiverem sendo executadas em um novo sistema com pequenas tabelas que crescerão. E, finalmente, mas o mais importante, quão rápida é essa consulta e quantos recursos ela usa. O último ponto pode não parecer tão importante, você pode estar pensando que levar menos de 3 segundos é bom o suficiente, mas se pudesse ser executado em <1 segundo, não seria melhor? Se seus bancos de dados estiverem hospedados na nuvem, a redução de recursos também poderá economizar dinheiro.

Muitos casos de otimização de SQL normalmente vêm de um problema detectado pelo usuário final ou pelo software de monitoramento. “Por que este relatório está demorando 30 minutos para ser gerado?”, “O que está causando esse pico na espera de E/S” ou “Por que esses trabalhos estão demorando duas vezes mais para serem executados do que no ano passado?”

Em todos esses cenários ainda se resume a algum conhecimento sobre os planos de execução e a melhor forma de corrigir o SQL para melhorar a situação e isso pode ser muito demorado e nem sempre bem-sucedido.

Vamos dar um exemplo. Então, você está escrevendo uma nova consulta, executando-a e pensando, oh, querido, isso está demorando muito.



17 segundos para 730 linhas, o que devo fazer?

Primeiro, vamos revisar o plano de execução:



Isso nem sempre é direto se você precisar aumentar e diminuir o zoom para entender. Portanto, o primeiro conselho é obter um bom visualizador de planos como este com o Spotlight Tuning Pack.



O visualizador de plano destaca as principais informações de que precisamos e onde estão as principais operações, além de destacar quaisquer avisos.

Aqui está um exemplo:



Então, há um problema com este código, mas o que podemos fazer sobre isso?



Bem, na verdade bastante. Podemos usar dicas de consulta, adicionar alguns índices (não esqueça que isso pode afetar outras consultas e DML), adicionar bits de código que não alteram o conjunto de resultados, mas influenciam o otimizador a gerar um plano diferente e pequenos truques para pare o otimizador considerando um determinado índice que está usando e talvez gere um novo plano. Mas isso é tudo tentativa e erro e muito demorado para fazer manualmente.

Ao adicionar o aplicativo Spotlight Extensions ao SSMS e assinar o Spotlight Tuning Pack, podemos deixar que o recurso de otimização do Tuning Pack faça todo o trabalho pesado por nós.

Você deve ter notado na primeira captura de tela que, quando o recurso é ativado, ele detecta automaticamente que a otimização é possível:



Clique em Ver Análise



Você pode então clicar no botão Otimizar e o mecanismo otimizador analisará o código e começará a aplicar regras de reescrita que alterarão a sintaxe do SQL fornecendo alternativas que fornecem o mesmo conjunto de resultados e, em seguida, testá-las para que possamos ver se alguma execução alternativa planos são mais rápidos e por quê. As regras são aplicadas em combinações para que as alternativas possíveis sejam superiores a 100. No entanto, a ferramenta só mostra alternativas mais rápidas que a original.



Esse processo é executado em segundo plano e economiza muito tempo se você tentar fazer isso manualmente.

E quando os resultados são mostrados você pode comparar as alternativas, ver as diferenças de código, comparar os planos e revisar as estatísticas.



Então, de volta ao SSMS com minha nova versão da consulta e teste-a.



Sucesso.

Se estiver em um ambiente de desenvolvimento, você pode considerar liberar o cache de buffer usando DBCC DROPCLEANBUFFERS para testar suas consultas com um cache de buffer frio sem desligar e reiniciar o servidor.

Além disso, considere adicionar SET STATISTICS IO ON à consulta para obter mais informações sobre por que a sintaxe da consulta fez a diferença:

Original:



Reescrever:



E isso também pode ser alcançado no Tuning Pack com o recurso de comparação de estatísticas:



Assim, com a mudança bem-sucedida e o usuário final satisfeito, vamos para a próxima consulta. Ao melhorar continuamente o desempenho de consultas individuais, melhoramos o desempenho da instância.