Ajuste do desempenho da consulta

12

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?


fonte

Respostas:

8

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.

Mark Storey-Smith
fonte
5

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, dont 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.

Richard
fonte
0
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.).

Cara
fonte
Mas para consultas executadas quando não houver no cache de consultas, as leituras físicas serão maiores que zero, certo? Quero dizer, nem sempre é possível contornar isso, pois nem todas as consultas (principalmente as ad hoc) são armazenadas em cache. Estou correcto?
Thomas Stringer
@ Surfer513 para cuidar do cache de dados, você pode emitir um CHECKPOINT seguido por um DBCC DROPCLEANBUFFERS para limpar o buffer pool (cache de dados). Observe que isso limpará os buffers para todos, portanto, use-os de acordo (nos sistemas de teste).
precisa saber é o seguinte
@ StanleyJohns, por que você deseja limpar o cache de dados / consultas?
Thomas Stringer
Dessa forma, o IO físico será o mesmo a cada vez, fornecendo a consistência necessária para o teste. Isso ajudará no ajuste fino da consulta.
precisa saber é o seguinte
Eu ignoraria as estatísticas físicas de E / S, pois estão sob o controle da infraestrutura subjacente e incorporarei o buffer da SAN e do SO. As E / S lógicas são uma medida da quantidade de TRABALHO que a instrução SQL tinha que fazer. Se o SQL fizer menos IO lógico, ele funcionará menos.
Guy