Durante nossas consultorias sobre otimização de aplicações, um gargalo constante que nos deparamos é o banco de dados. Na maioria dos casos, o problema raiz é a falta de atenção na escrita de consultas e comandos SQL, o que resulta em planos de execução não ideais, possivelmente, ofensores de performance ao ambiente.

Conhecer mais sobre planos de execução SQL, ajuda os engenheiros de software a realizarem otimizações nas consultas. Estas otimizações, se bem feitas, geram uma nova vida para as aplicações, sem falar, é claro, em uma possível redução dos custos com a infra do banco de dados..

Em uma conversa para a Exímia Talks, com o Elemar JR, abordamos vários insights a respeito do assunto, dentre os quais podemos destacar como sendo os principais:

O índice clustered é o mais importante da tabela

Nosso Highlander para cada tabela (alusão nerd detectada): Só pode existir um (ele é a própria tabela). Planeje-o com a devida atenção. Quando definida uma chave primária, ela é criada como clustered por padrão. Mas isso não é uma obrigatoriedade. Se a grande maioria dos acessos à tabela não são por ela, reveja a modelagem.

O plano de execução é quem dita as regras

Sempre analise ele. Quanto menor a sua complexidade, na teoria, mais performance irá ter. Quanto menor o trabalho do banco de dados para recuperar os dados, menos recursos será preciso do ambiente, consequentemente, menos tempo de duração de uma consulta.

Evite fazer acessos recorrentes a mesma tabela em uma mesma consulta

Se possível, escreva-a de modo que recupere somente os dados realmente necessários, evitando que seja lido muito mais páginas do que preciso. Em alguns casos, é válido
recuperar uma gama um pouco maior dos dados e montar uma expressão que trata ele de modo a ter os mesmos resultados. Avalie cada caso.

Defina índices realmente assertivos

70% dos problemas de performance em banco de dados são resolvidos com eles. Por isso, o intuito de criá-los é de melhorar significativamente métricas como CPU e Memória em detrimento ao Armazenamento. Caso seja necessário penalizar alguma dessas métricas, opte pela Storage. Embora você onere a escrita, a cada novo índice criado, na imensa maioria dos casos é a leitura que causa os principais problemas no seu ambiente de banco de dados.

Por mais simples que seja uma consulta, dê a devida atenção para verificar se ela não tem qualquer desperdício

Quando a mesma for liberada em produção e tiver outros fatores além da própria execução da consulta em si (concorrência, paralelismo, bloqueios), esta pode ser desastrosa no seu ambiente. Previna antes que o problema ocorra, efetuando antecipadamente essa análise, evitando assim, deixar dinheiro na mesa, quando a única solução será upgrade da Infra.

Não existe uma solução definitiva em SQL

Uma mesma consulta escrita de forma diferente, pode ter resultados ainda mais satisfatórios. Entenda os recursos da linguagem que estão disponíveis hoje em dia e encontre uma forma mais eficiente de resolver o mesmo problema do passado. Procure optar pela solução “set based” ao invés de “row by row” para o banco performar de acordo.

Pense fora da caixa

Embora SQL (Structured Query Language) não seja uma linguagem considerada nova, várias melhorias foram incluídas com o passar do tempo, para resolver problemas já conhecidos em relação a processamento de conjuntos de dados. Use e abuse de window functions, pois a performance delas, geralmente é superior às soluções de outrora.

Conclusão

O intuito deste rápido artigo é sintetizar os principais pontos abordados no vídeo para o canal da Exímia CO no youtube, na qual Elemar JR e um especialista em determinado assunto, têm a oportunidade de falar sobre as questões que surgem no dia a dia da consultoria, em nossos clientes. No vídeo, discutimos sobre um caso real de tuning, na qual uma simples consulta era tão onerosa que quando executada pela aplicação, causava instabilidade no servidor do banco de dados do cliente. Quando vários usuários simultâneos a executavam, o cenário se tornava ainda mais grave, “topando” totalmente o processamento do servidor. O objetivo foi transmitir um pouco da linha de pensamento utilizada para resolver o problema em questão, mostrando uma solução que nem sempre é trivial de ser percebida, mas que quando aplicada, faz diferença no uso otimizado dos recursos computacionais do ambiente do banco de dados.