Como posso saber se minha consulta é boa o suficiente para produção?

Como posso saber se minha consulta é boa o suficiente para produção?


Quando faço essa pergunta, aqui estão algumas coisas que penso:

  • Quantas vezes vou executá-lo? É uma tarefa única ou será executada milhares de vezes por segundo na página inicial de um site popular?
  • A que horas do dia / semana vai funcionar? Estamos com cargas de pico então, ou é uma coisa depois do expediente?
  • Este servidor geralmente faz um pequeno trabalho transacional ou é um servidor de relatórios?
  • Minha consulta vai travar enquanto é executada?

Então, armado com essas coisas, avalio minha consulta em termos de:

  • Duração – não apenas tempo, mas também paralelismo: quantos núcleos estou amarrando e por quanto tempo?
  • Lê – a quantidade de dados que está lendo
  • Concessão de memória – o que pode afetar drasticamente outras consultas em execução

Para mostrar o que quero dizer, vou escrever uma consulta no banco de dados Stack Overflow, medi-la e decidir se é boa o suficiente – ou se preciso ajustá-la para ir mais rápido.

Aqui está minha consulta.

Quero mostrar as 250 principais perguntas marcadas com SQL Server:

Para descobrir se é bom o suficiente para produção, começo executando isto:

Quando eu executo isso, ele ativa um novo conjunto de mensagens na saída da minha consulta. É totalmente seguro executar, mesmo em produção, e não afeta as consultas de ninguém – apenas as minhas.

Em seguida, clico em Consultar, Incluir Plano de Execução Real. Isso permite uma representação visual do que o SQL Server está fazendo para executar a consulta. Se você vem de outras plataformas de banco de dados, pode ter se referido a isso como um plano de exibição ou um plano de consulta. Em seguida, execute a consulta.

Primeiro, observe as estatísticas de tempo da consulta.

Quando terminar, olhe para a guia Mensagens:

Como posso saber se minha consulta é boa o suficiente para produção? 2

Veja os tempos de execução na parte inferior da captura de tela:

Se você estiver ajustando um procedimento armazenado ou lote com várias consultas nele, o último conjunto de tempos de execução será o total em todo o lote.

Não costumo sintonizar usando o tempo porque é muito imprevisível. Pode variar com base em:

  • O que mais o SQL Server está fazendo no momento
  • Quanto está no cache em relação ao obtido do disco
  • O que mais o armazenamento está fazendo no momento

Além disso, os números de tempo podem variar muito de servidor para servidor. Coisas para pensar:

  • O seu servidor é do mesmo tamanho da produção?
  • O seu banco de dados tem o mesmo tamanho da produção?
  • Seu servidor tem outras diferenças em relação à produção, como diferentes configurações, número de versão ou nível de patch?

Como eles podem variar muito, não me importo muito com os tempos de execução de consulta exatos. Quando estou olhando às vezes, eu apenas me pergunto:

  • Estou no estádio certo? Por exemplo, se estou escrevendo uma consulta transacional que acessa uma pequena quantidade de dados, provavelmente ela precisa ser concluída em um ou dois segundos. Se estou escrevendo um relatório, pode ser necessário terminar em 10-30 segundos.
  • O tempo de CPU é maior do que o tempo decorrido? Nesse caso, isso indica que minha consulta foi paralela a vários núcleos de CPU. Uma consulta de 5 segundos que dificilmente gasta tempo de CPU pode não ser grande coisa, mas se for 5 segundos e o tempo de CPU for 40 segundos, isso indica que minha consulta atingiu o máximo de 8 núcleos de CPU em todos os 5 segundos. Não vou conseguir executar muitas dessas consultas, então provavelmente vou precisar ajustar isso.

Em seguida, observe as leituras lógicas da consulta.

Mais perto do topo dessa captura de tela, o SQL Server retornou uma linha de mensagens para cada tabela que tocamos:

Destaque essas coisas, copie-as, vá para StatisticsParser.com e cole-as. Você obterá uma bela grade com totais em toda a consulta:

Como posso saber se minha consulta é boa o suficiente para produção? 3

Concentre-se na coluna “Leituras lógicas”: esse é o número de páginas de 8 KB que sua consulta lê – independentemente de essas páginas estarem na memória ou obtidas do armazenamento. (Se você estiver usando índices columnstore, também desejará examinar as leituras lógicas LOB, porque os índices columnstore armazenam seus dados de maneira um pouco diferente.)

De modo geral, quanto mais páginas sua consulta lê, mais lenta ela irá.

Quanto mais você souber a carga de trabalho do seu próprio servidor, terá uma ideia dos tipos de leituras que ele pode suportar sem que os usuários gritem de agonia. Quando você está apenas começando, pode dizer que as consultas transacionais que fazem 100.000 leituras ou mais provavelmente serão um problema. Mesmo muito mais baixos, eles podem ser um problema – mas se você vir leituras de seis dígitos, provavelmente é hora de pisar no freio e fazer alguma consulta ou ajuste de índice. 128.000 páginas equivalem a 1 GB de dados e, se você estiver lendo 1 GB de dados apenas para realizar uma transação curta, é provável que seja um problema.

Para obter pontos de bônus, observe o próprio plano.

Quanto mais confortável você ficar com o ajuste de consulta, mais poderá detectar comportamentos com os quais pode não se sentir confortável:

Como posso saber se minha consulta é boa o suficiente para produção? 4

Por exemplo, no plano da minha consulta:

  • Há um estrondo amarelo no operador Sort, o que indica que minha consulta ficou sem memória e teve que classificar coisas no TempDB.
  • Existem ícones de paralelismo em muitos dos operadores, indicando que o SQL Server acreditava que faria muito trabalho, por isso alocou vários núcleos de CPU para a tarefa. Isso não é necessariamente um problema por si só – isso pode ser bom em uma grande consulta de relatório – mas se estou trabalhando em um sistema transacional em que as consultas devem terminar em 1 ou 2 segundos, talvez seja necessário ajustar a consulta ou os índices para reduzir o trabalho necessário.
  • Existem carimbos de data / hora em cada operador, ajudando a indicar quais operadores demoraram mais. As métricas não significam o que você pensa, porém: Erik Darling explica que os operadores de modo de linha e modo de lote controlam o tempo de maneira diferente.

Mas faça o que fizer, não olhe para os tempos no plano de consulta.

Se você clicar com o botão direito do mouse no ícone SELECIONAR no plano e clicar em Propriedades, verá uma seção chamada QueryTimeStats, circulada aqui:

Como posso saber se minha consulta é boa o suficiente para produção? 5

Faça o que fizer, NÃO ZOOM E OLHE PARA ISSO:

Como posso saber se minha consulta é boa o suficiente para produção? 6

Porque se você fizer isso, você vai começar a fazer perguntas como: “Por que essas estatísticas de CPU e tempo decorrido não correspondem ao que eu vi na guia Mensagens?”

E então você vai perceber que todos esses dados são construídos sobre um trono de mentiras, e nenhum de nós tem certeza de que qualquer um desses números está certo. Basta manter a simplicidade e se concentrar em leituras lógicas. (Eles também não são tecnicamente precisos: eles não mostram leituras feitas pela maioria das funções definidas pelo usuário, por exemplo, mas há apenas um limite para o que posso ensinar em uma única postagem no blog.)

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br
Leia Também  Atualizando meu jogo de treinamento novamente: Configuração do My Home Office Studio: Primavera 2020