Introdução
A consulta SQL descreve o resultado esperado, não a maneira de obter o resultado. O conjunto de etapas específicas que o servidor deve seguir para retornar o resultado é chamado de plano de execução da consulta. O plano é construído pelo otimizador. A seleção de um plano afeta a velocidade de execução, o que o torna um dos elementos mais importantes da análise de problemas de desempenho de consultas.
O plano de execução compreende operadores e suas propriedades que estão inter-relacionadas entre si na forma de estrutura em árvore. Cada operador é responsável por uma operação lógica ou física separada. Todos juntos, eles garantem o resultado descrito no texto da consulta. Dentro da árvore, os operadores são representados pelos objetos de classe na memória do SQL Server. Os usuários do servidor (ou seja, você e eu) veem a descrição gerada no formato XML com um esquema específico, que é exibido graficamente pelo ambiente SQL Server Management Studio (SSMS).
Existem muitas operadoras de planos e ainda mais propriedades. Além disso, novos surgem de tempos em tempos. Este artigo não se atreve a descrever toda a variedade possível de operadores. Em vez disso, gostaria de compartilhar as adições mais interessantes neste assunto e lembrar alguns elementos antigos, mas úteis.
Versão do servidor
Às vezes, você pode encontrar solicitações para a versão do servidor nos fóruns, mesmo que o plano de consulta seja fornecido no formato correto (XML). Em vez disso, você pode economizar tempo e abrir o plano de execução como XML. E o primeiro elemento que descreve o plano mostrará a versão do servidor na propriedade Build.
Este método não permite recuperar informações completas sobre a edição do servidor, mas na maioria dos casos é suficiente para entender com o que lidamos.
Número de linhas da tabela
A segunda pergunta frequente é “Quantas linhas sua tabela contém?”. Essas informações também podem ser recuperadas do plano de consulta (a partir da versão 2008 do servidor). Para isso, precisamos selecionar o operador de acesso a dados (Scan ou Seek) de uma tabela em questão e dar uma olhada na TableCardinality propriedade. Há mais uma propriedade interessante, Estimated Row Size, para especificação do tamanho da linha e avaliação aproximada do tamanho da tabela ou índice (desde que a tabela não esteja compactada).
Eu gostaria de observar que este não é um número real de linhas em uma tabela, mas dados das estatísticas dos objetos. No entanto, esses dados são a base para as decisões que o otimizador toma ao criar uma consulta.
Contexto
O plano de consulta salva as configurações SET notáveis para as quais foi criado. Para visualizar as configurações, você precisa selecionar um elemento raiz no plano e expandir as Definir opções propriedade. Por exemplo, podemos saber se o plano foi construído com o ARITHABORT opção habilitada (a diferença dessa configuração geralmente leva a dois planos e situações diferentes com sniffing de parâmetro ruim).
Número de CPUs
Podemos recuperar o número de processadores disponíveis para o otimizador. Para isso, precisamos abrir o OptimizerHardwareDependentPropertie s -> EstimatedAvailableDegreeOfParallelism parâmetro no mesmo elemento raiz e multiplique por 2. Se apenas um processador estiver disponível, não há necessidade de multiplicar.
2*2 =4, 4 CPUs estão disponíveis. Na verdade, eu tenho um processador de 4 núcleos no meu computador e todos os 4 núcleos estão disponíveis para o servidor. Essas informações podem ajudá-lo a detectar a máquina na qual o plano foi gerado.
Versão do Estimador de Cardinalidade
A partir do SQL Server 2014, várias versões do Cardinality Estimator (RU) ficaram disponíveis. Esse mecanismo afeta a maioria das decisões que o otimizador toma ao selecionar um plano. Você pode recuperar a versão do Cardinality Estimator do CardinalityEstimationModelVersion propriedade do operador raiz.
- 0 – SQL Server <=2012
- 120 – SQL Server 2014
- 130 – SQL Server 2016
- 140 – SQL Server vNext
Tempo de execução da consulta e tempo de espera
A partir do SQL Server 2016 SP1, o plano de consulta real apresenta informações sobre o tempo de execução e o tempo do processador. Para recuperar esses dados, você precisa expandir o QueryTimeStats propriedade no elemento raiz e visualize os valores de CpuTime e Tempo Decorrido . Não precisamos habilitar a coleta de tempo de execução ou perguntar “quanto tempo a consulta foi executada?” mais – todas essas informações estão incluídas no plano.
A segunda melhoria notável é o top 10 das esperas mais longas durante a execução da consulta. Para isso, precisamos expandir o WaitStats propriedade no elemento raiz. Essa adição permite obter motivos mais exatos da execução lenta de consultas e simplifica significativamente o diagnóstico.
Tipos de parâmetro
A Lista de Parâmetros A propriedade, que lista os parâmetros usados na consulta, existia no plano há muito tempo. No entanto, a partir do SQL Server 2016 SP1, o Tipo de dados do parâmetro foi adicionada à definição do parâmetro. Esta propriedade armazena o tipo de dados do parâmetro. Pode ser útil para entender problemas com a conversão de tipo.
Número de linhas lidas e número estimado de linhas a serem lidas
O plano de execução inclui duas propriedades muito importantes, Número real de linhas e Número estimado de linhas. Essas propriedades contêm informações sobre o número de linhas retornadas pelo operador de leitura de dados, mas não o número de linhas que ele realmente leu. As propriedades Número de linhas lidas e Número estimado de linhas a serem lidas respondem a essa pergunta e permitem recuperar o número de linhas que o servidor realmente leu ou vai ler. A propriedade ActualRowsRead (Número de Linhas Lidas no SSMS) está disponível a partir do SQL Server 2012 SP3, 2014 SP2, 2016 SP1. O EstimatedRowsRead (Número estimado de linhas a serem lidas no SSMS) está disponível a partir do SQL Server 2016 SP1.
Estatísticas de E/S e Tempo de Execução do Operador
Existem várias propriedades muito úteis estabelecidas no SQL Server 2016, 2014 SP2 e disponíveis no plano de consulta real. São métricas de E/S (se um operador tiver E/S) – Estatísticas de E/S reais, métricas de CPU e tempo de execução – Estatísticas de tempo real e métricas de memória (a partir de 2016 SP1, se um operador precisar de memória).
As propriedades incluem as seguintes novas métricas que podem ser divididas em threads no caso do plano paralelo:
- RealElapsedms
- CPUms Reais
- Verificações reais
- Leituras Lógicas Reais
- Leituras Físicas Reais
- RealReadAheads
- RealLobLogicalReads
- RealLobPhysicalReads
- RealLobReadAheads
- InputMemoryGrant
- OutputMemoryGrant
- UsadoMemoryGrant
Como você pode ver na lista acima, você pode recuperar informações abrangentes sobre a execução de qualquer operador, E/S consumida e memória. Nas últimas versões do SSMS, essas métricas são representadas na janela de propriedades. Se você usa uma versão antiga do SSMS, pode recuperá-los abrindo o plano como XML. Na minha opinião, agora tem tudo para mostrar os percentuais não pelo custo estimado, mas pelos recursos reais decorridos (criei uma sugestão no Connect. Então, se você gostou da ideia, vote nela).
Informações sobre sinalizadores de rastreamento ativados
Os sinalizadores de rastreamento no SQL Server são ‘comutadores’ especiais do comportamento do servidor padrão para algum comportamento diferente. A partir do SQL Server 2014 SP2 e 2016 SP1, as informações sobre sinalizadores de rastreamento habilitados estão disponíveis na propriedade TraceFlags do elemento específico. Pode incluir até 100 sinalizadores habilitados simultaneamente no momento da construção da consulta.
Informações sobre derramamento de dados para tempdb
Alguns operadores de plano, por exemplo, como Sort ou Hash Match, exigem memória durante a execução da consulta. No entanto, o volume de memória é calculado no momento da compilação. Devido a vários motivos (por exemplo, avaliação incorreta do suposto número ou linhas), o volume de memória pode ser calculado incorretamente. Se menos memória for alocada do que o necessário para execução, o servidor terá que derramar dados para tempdb. Isso retarda a execução da consulta. O cuidado com essa situação foi introduzido no servidor 2012, mas a partir do SQL Server 2012 SP3, 2014 SP2, 2016, as informações de diagnóstico foram expandidas e agora incluem o volume de dados derramados e dados lidos. Assim, você pode avaliar o problema e tomar as medidas adequadas.
Conclusão
O plano de execução inclui muitas informações úteis, o plano de consulta real inclui ainda mais informações e o plano de consulta real nas últimas versões do SQL Server é apenas uma mina de informações úteis. Este artigo não se destina a ensinar alguém a analisar planos de consulta. Em vez disso, considerei as propriedades do plano mais interessantes, incluindo propriedades novas e antigas, mas subestimadas. Espero que este artigo o ajude na próxima vez que você precisar analisar o desempenho da consulta.
O artigo foi traduzido pela equipe do Codingsight com a permissão do autor.
Ferramenta útil:
dbForge Query Builder for SQL Server – permite que os usuários criem consultas SQL complexas de maneira rápida e fácil por meio de uma interface visual intuitiva sem escrita manual de código.
