Escrever um bom SQL: uma arte esquecida?

Instruções SQL mal-escritas podem causar problemas de desempenho significativos no ambiente de banco de dados, adverte o vice-presidente de Marketing de produtos da SolarWinds, Gerardo Dada. Uma recente entrevista com um painel de especialistas determinou que o SQL mal-escrito pode causar até 70% de problemas gerais de desempenho.

A adição de recursos pode mascarar vários dos problemas que acompanham um SQL mal-escrito, mas isso tem um preço. A arte de escrever SQLs de boa qualidade (incluindo códigos de bloco: procedimentos armazenados, pacotes, funções etc.) está morrendo? E se é uma arte tão importante, por que isso está acontecendo?

Com o custo necessário para provisionar recursos de hardware adicionais, por que não deixar rolar? A maioria dos principais mecanismos RDBMS é licenciado de acordo com o número de processadores (núcleos) em que são executados ou foram executados (no caso de ambientes virtualizados); portanto, o custo de adicionar mais hardware a um problema de desempenho não se limita apenas ao custo do hardware adicional. Esse custo oculto torna ainda mais importante o ajuste do SQL, pois só assim os sistemas podem fazer mais com menos.

Dada observa que para diversas empresas onde ele trabalhou implementaram a solução de adicionar hardware. O especialista, no entanto, destaca que esse não é o único fator que desmotiva a aplicação de mais esforços ao ajuste de SQL. Ele enumera outros fatores importantes:

Geralmente, os desenvolvedores usam lógica algébrica. Quando solicitados a escrever SQL, eles precisam mudar para uma lógica baseada em conjunto (pense nos diagramas de Venn). Essa mudança de contexto significa que eles precisam pensar diferente durante grande parte do tempo que passam criando códigos.

É muito importante garantir, ainda durante o desenvolvimento, que os resultados corretos sejam obtidos (seja em uma consulta ou uma transação) ao executar SQL em um banco de dados. Os ambientes de desenvolvimento não costumam ser dimensionados de acordo com o tamanho dos sistemas de produção; portanto, os testes não revelam antecipadamente problemas de desempenho ocasionados por SQL mal-escrito. Então, aparentemente não há nada com que se preocupar.

O uso de ferramentas de mapeamento objeto-relacional (ORM, Object-Relational Mapping) ganhou popularidade. Essas ferramentas nem sempre produzem SQLs bem-ajustados para nossos ambientes de banco de dados exclusivos.

Os desenvolvedores (também sou culpado) gostam de reutilizar códigos. Quando realizada sem critério, essa técnica pode fazer com que as instruções SQL sejam ajustadas apenas o suficiente para obter os resultados necessários, ou seja, as implicações na escalabilidade e no desempenho não são exploradas.

É difícil escrever um bom SQL quando os modelos de dados são ruins. Isso pode significar tabelas enormes com dados que vão desde o início, uso incorreto de indexação e normalização inadequada à finalidade do aplicativo; isso para citar apenas alguns fatores.

Falta de entendimento das tabelas de base. Ao mesclar várias tabelas, não é incomum a falta de noção sobre quais delas devem ser usadas como tabelas de base (incluídas anteriormente no plano otimizador para que um número menor de linhas precise ser avaliado posteriormente).

Falta de entendimento ao ler planos de execução. Como é possível ajustar o SQL sem saber o que deu errado? Eu incluiria neste item o pressuposto questionável de que o custo otimizador associado a uma etapa do plano é exato.

Se o foco é a produtividade (que, em desenvolvimento, geralmente assume a forma de linhas de código), raramente fazer direito é tão valorizado quanto fazer mais.

O vice-presidente de Marketing de produtos da SolarWinds adverte que a arte de escrever um bom SQL pode estar correndo o risco de morrer em ambientes de desenvolvimento e banco de dados. Para Gerardo Dada, vários fatores contribuem para o desaparecimento dessa habilidade.

Nem mesmo os fornecedores de mecanismos de banco de dados se sentem incentivados a corrigir SQLs mal-escritos, pois o lucro deles pode aumentar devido aos custos de licenciamento adicional quando o hardware é usado para reduzir o impacto.

Com frequência, os problemas de instruções SQL só são descobertos quando liberados durante a fase de produção. Isso pode causar contenção entre as pessoas que escrevem o código e as pessoas cuja tarefa é oferecer suporte/responder às preocupações de produção.

*Com informações da SolarWinds