A adoção de boas práticas de sintaxe SQL e escrita de consultas melhorará a eficácia do monitoramento do banco de dados e, como resultado, melhorará o desempenho geral do banco de dados. Existem várias maneiras testadas e comprovadas de melhorar o desempenho do banco de dados por meio de ajustes de sintaxe e consulta. Escolhemos 5 para focar.
1. Expressões CASE
Aqui estão algumas práticas recomendadas para obter o melhor desempenho das expressões CASE:
- As expressões CASE melhoram o desempenho movendo o código procedural antigo para o código declarativo que pode ser otimizado. Para expressões CASE básicas, use
, que é o mais facilmente otimizado. Para expressões CASE estendidas, hashing e outras técnicas serão as mais úteis. - Como as cláusulas WHEN são testadas da esquerda para a direita, é melhor organizar suas cláusulas de modo que as mais prováveis sejam listadas primeiro. Isso reduzirá o tempo gasto em varreduras desnecessárias.
- A maioria dos otimizadores também considera testes redundantes considerando a ordem de execução. Assim que uma cláusula WHEN é executada, não há necessidade de testar essa cláusula novamente. No entanto, muitos otimizadores não são bons em ler expressões CASE aninhadas, então é melhor nivelá-las em um único nível.
2. Double-dipping e a cláusula da janela
No SQL, “double-dipping” significa visitar a mesma tabela mais de uma vez, o que torna sua consulta mais lenta. Idealmente, tente fazer todos os seus trabalhos em uma única visita à mesa. Mas se isso não for possível, existem algumas maneiras de mitigar o impacto no desempenho.
Usar tabelas temporárias construídas a partir da mesma tabela base unidas realmente não é a melhor maneira de evitar mergulhos duplos. Uma solução melhor é usar o otimizador do seu mecanismo SQL para exibir VIEWs e compartilhar os resultados como uma tabela de trabalho.
Se você estiver limitado a um otimizador menos que estelar, use tabelas temporárias e faça o trabalho manualmente.
Embora os métodos acima sejam perfeitamente aceitáveis, a melhor maneira de evitar a imersão dupla é usar a cláusula window porque as subcláusulas operam de maneira semelhante aos recursos de subconsulta. Por exemplo:
- A cláusula PARTITION BY é como um GROUP BY local que divide a tabela em agrupamentos.
- A cláusula ORDER BY impõe uma ordem de classificação.
- O quadro da janela (ROW ou RANGE) é como uma cláusula WHERE local.
Você pode otimizar as funções da janela seguindo estas regras:
- No índice, classifique primeiro as colunas da cláusula PARTITION BY e, em seguida, as colunas usadas na cláusula ORDER BY.
- Inclua qualquer outra coluna referenciada na consulta como colunas incluídas do índice.
3. Use procedimentos armazenados
Os mapeadores relacionais de objeto (ORMs) causam vários problemas de desempenho quando geram seu próprio código. Se você precisar usar ORMs, escreva seus próprios procedimentos armazenados para que o desempenho não sofra.
Há muitas maneiras de usar procedimentos armazenados para melhorar o desempenho, incluindo:
- Eles enviam menos dados pela rede, então as transações são mais rápidas
- Eles permitem chamadas mais curtas
- Os procedimentos armazenados são mais fáceis de rastrear nas ferramentas de perfil
- Como um procedimento armazenado é um objeto real em seu banco de dados, é mais fácil obter estatísticas de desempenho, o que facilita a localização de problemas de desempenho
- A reutilização do plano de execução aumenta
- Eles facilitam o tratamento de casos extremos e adicionam auditoria ou comportamento de bloqueio de alterações
- Os procedimentos armazenados não são vulneráveis a ataques de injeção de SQL
4. EXCLUIR e ATUALIZAR em lotes
A exclusão ou atualização de muitos dados de uma varredura de tabela grande usa muitos recursos porque ambas as instruções são executadas como uma única transação. Este é um assassino de desempenho porque se ocorrer um erro enquanto a transação estiver em execução e você precisar interrompê-la, o sistema precisará reverter a transação inteira. A reversão de grandes quantidades de dados consome muito tempo e bloqueia outras transações.
Você pode evitar esse problema de desempenho fazendo atualizações e exclusões em pequenos lotes. Quando você executa essas transações em lotes, se a transação for eliminada, a reversão será muito menor. A reversão de uma pequena quantidade de dados não leva muito tempo, e outras transações podem funcionar enquanto o lote é confirmado no disco.
5. Não recupere mais colunas do que você precisa
Uma das principais causas de consultas com desempenho insatisfatório é a recuperação de colunas estranhas. Evite práticas que geralmente resultam no retorno de um número excessivo de colunas. Tenha em mente o seguinte:
- O uso desnecessário de “SELECT *” em uma consulta provavelmente retornará mais colunas do que você precisa. Isso é um desperdício de recursos e bloqueia recursos de outros usuários. É especialmente importante não usar “SELECT *” indiscriminadamente em bancos de dados SQL colunares.
- Recortar e colar para reutilizar o código pode resultar em colunas estranhas.
- Ao invocar uma VIEW, você pode acabar com colunas aninhadas. Desaninhar consultas de baixo desempenho para verificar quais colunas estão lá e se livrar de colunas de tamanho excessivo que você não precisa. Uma boa indicação de que você tem um problema é que você tem uma cláusula WHERE com condições adicionais e uma cláusula FROM com junções externas adicionais.
Essas são apenas algumas das maneiras pelas quais adotar uma abordagem consciente da sintaxe SQL e da escrita de consultas pode melhorar o monitoramento do banco de dados. Não tenha medo de experimentar alguns outros. Um banco de dados de alto desempenho é fundamental para atingir as metas de negócios em todas as organizações.
