Processamento lógico e físico no SQL Server

Nas empresas existem projetos que foram construídos por especialistas que desenvolveram com qualidade e performance, atendendo as necessidades do cliente. E também existem outros tipos projetos, os quais foram construídos sem visar qualidade, feitos de qualquer maneira, sem a base de conhecimento necessária para a construção de um bom projeto.

Este tipo de projeto gera frustração pela área da empresa que o demandou e em alguns casos, pode até causar cancelamento de contratos, retrabalho, entre outras consequências.

Existem muitos problemas diferentes a serem abordados para compreender por que determinado projeto foi um sucesso e um outro projeto foi um fracasso. Esse tipo de análise está além do escopo deste artigo.

Mas entre os projetos que foram um sucesso, ter especialistas que realmente conhecem o seu trabalho, entendem o que estão fazendo e por que estão fazendo é um diferencial em qualquer equipe de desenvolvimento.

Decisões de especialistas sabem definir tempo, escopo e as melhores práticas no desenvolvimento de um projeto de sucesso.

Construir projetos de sucesso com qualidade e performance deve ser a prioridade de qualquer profissional. Para desenvolvedores de Transact-SQL (T-SQL) ou na forma abreviada T-SQL, realizar o desenvolvimento de forma performática e com qualidade consiste em ter uma base de conhecimento sólida.

Segundo o livro Inside Microsoft SQL Server 2008:T-SQL Querying, “os verdadeiros especialistas em diferentes campos têm uma prática em comum: eles são mestres do básico”.

Para que um especialista possa ser capaz de resolver qualquer tipo de problema em sua especialidade e desenvolver com qualidade, ele precisa entender como a ferramenta que ele usa realmente funciona.

Neste artigo, será abordado o funcionamento de uma consulta no SQL Server sob o ponto de vista lógico que seria uma forma conceitual de funcionamento da query. E também do ponto de vista físico que seria o plano de execução.

A partir da compreensão destes conceitos será possível determinar qual o melhor caminho a seguir, durante o desenvolvimento de um T-SQL, obtendo assim performance.

Processamento Lógico e Físico

A programação em Transact-SQL para a construção de queries tem vários aspectos que são singulares como, por exemplo, a ordem lógica que o SQL segue durante o processamento de uma query. Esta, por sua vez, é diferente da ordem na qual foi escrita.

Além disso, o processamento desta query pode ter sua performance influenciada por alguns fatores a serem considerados durante a construção dela, estes fatores só podem ser totalmente compreendidos após entender a lógica de processamento do SQL.

Entretanto, a lógica de processamento do SQL nem sempre é igual ao plano de execução gerado, que é o processamento físico da query.

O componente do SQL Server que gera o plano de execução é o query optimizer. Ele irá determinar qual ordem das tabelas acessadas, quais índices usados, qual os algoritmos para os joins que serão aplicados e assim por diante. Entre os vários planos que o optimizer vai gerar, o escolhido será o de menor custo.

Entende-se como processamento lógico as fases conceituais bem definidas de processamento de um T-SQL e o processamento físico como a forma como realmente o T-SQL será executado, o que geralmente segue a mesma ordem do lógico.

No entanto, o processamento físico pode alguma vezes determinar alguns atalhos a serem trilhados como, por exemplo, realizar um filtro antes que o processamento lógico o faria. Isso por que o papel do processamento físico é encontrar a melhor solução para processar a query no menor custo possível. Independente disso, o resultado do processamento lógico ou físico será sempre o mesmo.

Fases do Processamento Lógico

Geralmente, a ordem na qual o código é escrito numa linguagem de programação é a ordem no qual ele é processado. Porém, ao escrever uma consulta em T-SQL a ordem de processamento será diferente da escrita. Considerando uma instrução SELECT...FROM por exemplo, o processamento desta consulta não é iniciado pelo SELECT, mas pelo FROM.

Isso faz bastante sentido considerando que é o FRO ...