Conhecendo o Query Optimizer e Query Processor

Pessoal, hoje não posso dizer que estou postando uma nova dica, mas sim um pouco de informação sobre dois recursos extremamente importantes existente no SQL Server que utilizamos de forma indireta, em nossas transações.
Estou falando o Query optimizer e Query Processor!!!!
Espero que vocês pelo menos já tenham ouvido falar algo sobre estes recursos, caso contrário, segue abaixo um pouco de informações sobre cada um deles:
      Escolher o melhor caminho para chegar a determinado lugar pode ser considerado para muitos uma arte, isso porque sempre existem vários caminhos que levam ao mesmo destino. Executar uma tarefa da forma mais eficiente possível requer que o caminho percorrido seja o melhor dentre as centenas de variáveis que podem influenciar na escolha do melhor percurso.
      No SQL Server o responsável por calcular a maneira mais eficiente de acesso aos dados é chamado de Query Processor, ele é dividido em duas partes, o Query Optimizer e o Query Execution Engine. Entender como funciona e como interpretar o trabalho do Query Optimizer é uma das melhores maneiras de aprominorar seus conhecimentos no SQL Server.
  Quando um comando T-SQL é executado no SQL Server, o Query Processor(Processador de Querys) entra em ação  para gerar um Plano de Execução(Execution Plan).
 Este plano dirá qual é a melhor maneira de acessar os dados gastando menos recursos e com o desempenho mais eficiente. Podemos observar na a seguir a ação do Query Optimizer (em vermelho) e uma série de passos para compilar e executar um comando T-SQL.
Supondo que um SELECT simples, por exemplo, SELECT * FROM Funcionarios, seja enviado ao servidor, a primeira tarefa que o Query Processor fará com o comando é verificar se o mesmo está no Cache Plan(Cache do Plano de Execução). Caso ele não esteja em cache, o Query Processor enviará o comando para os processos de Parse e Bind.
O Parse/Bind executa um processo conhecido como Algebrizer. Durante este processo o SQL tenta encontrar possíveis erros de escrita na sintaxe e lógica do comando. O Algebrizer também expande as definições de comando, isso significa que ele troca “select *” por “Select col1, col2, col3

 

          Quando estamos realizando um “Select” sobre uma View, o SQL acessa a tabela de origem para ler os dados que serão exibidos sobre as colunas e tabelas utilizadas pela View.

          Após estas análises o Parse/Bind retorna um binário chamado Query Processor Tree, que é uma representação lógica dos passos necessários para a execução do comando SQL. O Query Processor Tree é enviado para o próximo passo da execução da consulta, que é a análise do Query Optimizer.

          Alguns comandos como por exemplo, Create Table não necessitam ser analisados pelo Query Optimizer, pois possuem somente uma forma de execução.

 

          Quando o Query Optimizer recebe o Query Processor Tree, ele dará inicio a uma série de análise a fim de encontrar qual é a maneira mais eficiente de acessar os dados desejados. O Query Optimizer trabalha baseado no custo de cada operador de acesso a dados, ou seja, ele tenta encontrar a maneira que gastará menos recursos para retornar os dados. Durante esta fase de análise o Query Optimizer realiza algumas tarefas:

        Identificação de todos os possíveis argumentos de pesquisa que podem ser especificados na cláusula Where;

        Verificar se existem Joins entre tabelas que devem ser otimizadas.

 

          Com base nesta simples representação gráfica podemos visualizar como o Query Optimizer funciona. Como podemos observar, o resultado chamado pelo Query Optimizer após sua análise será definido como Query Plan, ou Plano de Execução de Consultas.

          O Plano de Execução realiza a seguinte sequência de passos internos:

        (1) Todas as tabelas no FROM são unidas montando um plano cartesiano;

        (2) Os filtros baseados na cláusula ON são executados;

        (3) Os tipos de JOINs (LEFT, INNER, RIGHT, etc) são avaliados, para verificar que linhas devem ou não permanecer;

        (4) Os filtros da cláusula WHERE são aplicados;

        (5) As colunas na cláusula GROUP BY são aplicadas montando os grupos;

        (6) A cláusula WITH CUBE ou WITH ROLLUP é aplicada;

        (7) A cláusula HAVING é aplicada fazendo os filtros nos grupos;

        (8) A cláusula SELECT é montada;

        (9) As repetições são filtradas pelo DISTINCT ;

        (10) A ordenação é feita pelo ORDER BY; e

        (11) Os N primeiros registros são retornados pelo TOP.

Por enquanto é isso, espero que estas informações possam ajudar a esclarecer um pouco sobre o quanto o Query Optimizer e Query Processor são importantes para o SQL Server em seu funcionamento. Antes de encerrar este post, agradeço ao amigo Fabiano Neves Amorim por permitir utilizar este conteúdo que é de sua autoria.
Até a próxima.
Anúncios

Sobre Junior Galvão - MVP

Profissional com vasta experiência na área de Tecnologia da Informação e soluções Microsoft. Graduado no Curso Superior em Gestão da Tecnologia de Sistemas de Informação. Pós-Graduado no Curso de Gestão e Engenharia de Processos para Desenvolvimento de Software com RUP na Faculdade FIAP - Faculdade de Informática e Administração Paulista de São Paulo. Pós-Graduado em Gestão da Tecnologia da Informação Faculdade - ESAMC Sorocaba. Formação MCDBA Microsoft, autor de artigos acadêmicos e profissionais postados em Revistas, Instituições de Ensino e WebSistes. Meu primeiro contato com tecnologia ocorreu em 1995 após meus pais comprarem nosso primeiro computador, ano em que as portas para este fantástico mundo se abriram. Neste mesmo ano, comecei o de Processamento de Dados, naquele momento a palavra TI não existia, na verdade a Tecnologia da Informação era conhecida como Computação ou Informática, foi assim que tudo começou e desde então não parei mais, continuando nesta longa estrada até hoje. Desde 2001 tenho atuado como Database Administrator - Administrador de Banco de Dados - SQL Server em tarefas de Administração, Gerenciamento, Migração de Servidores e Bancos de Dados, Estratégias de Backup/Restauração, Replicação, LogShipping, Implantação de ERPs que utilizam bancos SQL Server, Desenvolvimento de Funções, Stored Procedure, Triggers. Experiência na Coordenação de Projetos de Alta Disponibilidade de Dados, utilizando Database Mirroring, Replicação Transacional e Merge, Log Shipping. Atualmente trabalho como Administrador de Banco de Dados no FIT - Instituto de Tecnologia da Flextronics, como também, Consultor em Projetos de Tunnig e Performance para clientes, bem como, Professor Titular na Fatec São Roque. Desde 2008 exerço a função de Professor Universitário, para as disciplinas de Banco de Dados, Administração, Modelagem de Banco de Dados, Programação em Banco de Dados, Sistemas Operacionais, Análise e Projetos de Sistemas, entre outras. Possuo titulações e Reconhecimentos: Microsoft MVP, MCC, MSTC e MIE.
Esse post foi publicado em Dicas. Bookmark o link permanente.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s