Ajuste do desempenho da consulta

Quando você termina de escrever uma consulta / proc / função armazenada, qual é a maneira mais informativa de obter rapidamente alguns parâmetros de desempenho? Você executa a consulta e visualiza o plano de execução real? Se sim, quais são as coisas que você procura? Obviamente, as varreduras de tabela / índice são as ocorrências de bits, mas o que mais?

Para uma avaliação rápida, obtenha o plano de execução do SSMS e no Plan Explorer .

• Revise as operações mais caras para algo inesperado. Classifica, tabelas de trabalho, operadores de junção inadequados (por exemplo, loop aninhado onde você espera uma mesclagem ou hash).
• Observe as contagens de linhas em cada estágio do plano, elas estão dentro do intervalo que você esperava ver?
• Veja as linhas estimadas vs reais. Se os valores reais estão próximos das estimativas, é mais provável que você tenha um bom plano. Se houver grandes variações, descubra o motivo (por exemplo, estatísticas ausentes e / ou desatualizadas).
• Avalie o potencial de problemas de detecção de parâmetros. Procure áreas nas quais a cardinalidade possa variar e teste em relação a vários parâmetros de entrada.

Muito material de referência disponível gratuitamente por aí, os Planos de Execução do SQL Server de Grant Fitchley são um bom começo. Também achei muito úteis as postagens no blog e o ebook de Joe Chang sobre os custos do plano de execução.

Principalmente, tudo o que faço é apenas executar a consulta e descobrir como ela é executada nos dados do mundo real. Se houver algum problema, analiso os planos de execução.

Quanto aos planos de execução, Brad McGehee tem um artigo interessante sobre o assunto.

Nele ele diz:

Se você vir algum dos itens a seguir em um plano de execução, considere os sinais de alerta e investigue-os quanto a possíveis problemas de desempenho. Cada um deles não é o ideal da perspectiva de desempenho.

* Index or table scans: May indicate a need for better or additional indexes.

* Bookmark Lookups: Consider changing the current clustered index, consider using a covering index, limit the number of columns in the SELECT statement.

* Filter: Remove any functions in the WHERE clause, don’t include wiews[sic] in your Transact-SQL code, may need additional indexes.

* Sort: Does the data really need to be sorted? Can an index be used to avoid sorting? Can sorting be done at the client more efficiently? 

Nem sempre é possível evitá-las, mas quanto mais você puder evitá-las, maior será o desempenho da consulta.

SET STATISTICS IO ON

Geralmente, o "número de leituras lógicas" deve ser o mais baixo possível. As poucas páginas tocadas para concluir a consulta, melhor o plano, como normalmente será mais rápido, menor impacto na CPU, RAM e E / S de disco.

Isso o guiará quando a alteração dos índices ou a re-fatoração do SQL estiver realmente ajudando. Observar o "tempo de execução em milissegundos" variará mesmo com o mesmo SQL e plano de consulta - as leituras lógicas permanecerão consistentes para qualquer plano de consulta.

Além disso, as "leituras físicas" devem ser muito baixas (e ser zero e permanecer zero nas execuções subseqüentes). Se isso não acontecer, verifique o uso da memória do SQL Server (duração da página, etc.).