Saúde Online A Saúde em tempo real
Artigos Relacionados
Instruções SQL mal-escritas podem causar problemas de desempenho significativos no ambiente de banco de dados. 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?
Por que se concentrar em ajustar instruções SQL?
Com o custo necessário para provisionar recursos de hardware adicionais, por que não deixar rolar? A maioria dos principais mecanismos RDBMS são licenciados 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.
Motivos pelos quais não nos concentramos em ajustar instruções SQL
Diversas empresas com as quais e para as quais trabalhei em minha carreira implementaram a solução de adicionar hardware. No entanto, esse não é o único fator que desmotiva a aplicação de mais esforços ao ajuste de SQL. Veja a seguir 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.
Agora está em produção!
Como mencionado, você pode citar vários motivos para não se concentrar mais no ajuste de SQL em ambientes de banco de dados. No entanto, talvez agora você esteja enfrentando uma redução significativa no desempenho da produção. Como isso é possível? Esse assunto poderia gerar uma coluna inteira, mas apontarei apenas algumas causas comuns para que os problemas só sejam descobertos quando o código chega na produção:
- São usados conjuntos de dados menores nos ambientes de pré-produção
- É muito difícil simular a carga de produção em ambientes de pré-produção
- Há falta de entendimento de casos de uso reais na produção
- Os dois primeiros itens da lista são caros
Conclusão
Acredito que a arte de escrever um bom SQL esteja correndo o risco de morrer em ambientes de desenvolvimento e banco de dados. 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. Eu gostaria de ver o ajuste de SQL entrar em foco novamente, o que traria vários benefícios, inclusive: a redução do TCO em organizações de TI, a diminuição da tensão entre disciplinas de TI e a satisfação de criar algo do qual se orgulhar, em vez de cumprir itens de uma lista de tarefas.
Gerardo Dada é vice-presidente de marketing de produtos da SolarWinds
