Ciclo de vida de uma query (SQL Server) - Parte 3

Faala galera, todos bem? Vamos continuar nossa jornada pelo ciclo de vida de uma query no SQL Server, hoje falaremos de uma das etapas mais "misteriosas" desse processo todo. Você também pode ver o post1 e o post2.

Chegamos na principal etapa desse ciclo.

Você enviou o seu comando para o SQL Server e ele não encontrou um plano de execução guardado na memória que atendesse ao seu comando, e agora?

Chegou a hora de brilhar, vaaaaaai Query optimizer! =)

Internamente o Command parser envia o seu comando em formato de "arvore de consulta" (query tree) para o Query Optmizer, que vai avaliar essa arvore se baseando no custo de cada etapa (tabelas envolvidas, quantidade de dados) com o objetivo de encontrar o caminho mais eficiente, um plano de execução que tenha o menor custo possível (sabe quando você vai pra praia e quer evitar engarrafamento e o waze ou maps te mandam por outro caminho? É por ai, ele traça a rota que ele considera ter o menor custo - ou distância - para te devolver os dados.).

Em um plano de execução (como você pode ver no exemplo abaixo) cada operador tem um custo "base", que é multiplicado pelo tamanho da linha e pelo numero que o SQL Server estimou de linhas a serem retornadas, essa conta gera o custo total do operador, somando o custo de todos os operadores temos o custo do plano de execução. Esse custo total é um indicador para representar o custo de recursos ao ambiente para esse plano de execução em questão.

Existem 3 fases que o query optimizer pode passar para gerar o plano de execução.

Um parêntese aqui, imagina que você quer comer uma pizza, você pode ligar na pizzaria e pedir (simples), pode ir no supermercado comprar aquelas que deixam prontas chegar em casa e assar para comer (da um trabalhinho), ou comprar todos os ingredientes e fazer tudo (gosta de complicar né hehe). O ponto é, quanto mais complexo for a tarefa mais atividades precisa fazer e "ferramentas e ingredientes" precisa ter.

Voltando ao SQL Server, quanto mais complexa é a query, mais caminhos e mais "ferramentas" o Query optimizer precisa para montar o plano de execução, por exemplo, na:

Fase 0: O otimizador não identifica mais de uma forma de resolver o que esta sendo pedido, quando a soma dos operadores que ele escolheu for < 0.2, será gerado um plano trivial (Trivial Plan). (o mesmo que ligar na pizzaria).

Fase 1: Ao passo que a query vai sendo incrementada e o seu custo(soma dos operadores) for >= que 0.2 e < que 1.0, o otimizador procura por padrões comuns que ja foram usados em outros planos, nesse caso é gerado um plano rápido (Quick Plan). (o mesmo que comprar e assar a pizza).

Fase 2: Essa ultima fase requer toda a capacidade do otimizador, ele é capaz de usar todas as suas possíveis regras de otimização para entregar o melhor resultado possível, são consideradas ações de paralelismo nesse estagio, com custo >= 1.0 é gerado o plano de otimização total (Full Plan). (o mesmo que comprar todos os ingredientes e fazer a pizza por completo).

Voltando a história que estamos contando desde o primeiro post (do restaurante), o filho do amigo do dono do restaurante não pode comer alimentos com glúten, e no cardápio não tem nenhuma opção sem glúten. O Chefe então cria uma receita na cabeça para atender o seu amigo que esta lá pra almoçar com o seu filho, ele não quer decepcionar, vai dar o seu melhor para criar o melhor prato no tempo mais rápido possível. Nesse caso, não tinha nada no cache (não tinha nenhuma receita pronta), ele fez do zero analisando a situação, a dificuldade, o que tinha de ingredientes e entregou o melhor resultado. Fase 2 - Full Plan, por exemplo.

No próximo post vamos avançar para a quarta etapa do processo!

Se você quer aprender muito mais e ser um(a) DBA SQL Server Jr faça parte da Iniciativa DBA (Saiba mais) !

Nos acompanhe em nossas redes sociais!

Grupo VIP Telegram: DBA On boarding

Youtube: DBA On boarding

Face & Instagram: DBA On boarding

Até a próxima, tchau!

#comunidadebd