Escrevendo queries otimizadas - SQL Magazine 84

Existem diversos pontos críticos que podem causar problemas de lentidão em um sistema, e estes, geralmente são difíceis de serem diagnosticados rapidamente com precisão. É muito comum situações de “stress tecnológico” dentro de uma empresa causada por lentidões aparentemente inexplicáveis em um ambiente estável. Geralmente isto ocorre sem que nenhuma parte envolvida no ciclo de vida e manutenção desse sistema tenha declarado novas implementações que poderiam ser apontadas como potenciais causadoras do problema e passíveis de uma investigação direcionada. Quando isso acontece em uma empresa sem uma política de desenvolvimento de software, sem controle e documentação de toda alteração realizada pelas equipes de Redes e Banco de Dados, começa uma corrida desordenada para solucionar o problema, com as áreas mirando para encontrar uma solução sem um alvo declarado.

Para evitarmos que este tipo de problema ocorra, nesta primeira parte do artigo vamos nos concentrar na construção de queries que visam o melhor desempenho, discorrendo em uma série de boas práticas que devem ser observadas ao se elaborar uma query.

Imagine o seguinte ambiente fictício: determinado dia, ao chegar ao trabalho, o DBA é interpelado pelos desenvolvedores para saber se alguma coisa estava acontecendo com o SGBD, pois o tempo de resposta de suas aplicações apresentava uma lentidão inexplicável. O DBA então verifica os logs do banco para ver se encontra alguma exceção reportada, e não encontra nada. Logo em seguida a equipe de redes é acionada para verificar se algo está ocorrendo na parte de infraestrutura, e mais uma vez nada é encontrado. E agora? O que pode estar acontecendo?

Certamente essa situação é mais comum do que se possa imaginar. Os próximos passos do DBA seriam monitorar o comportamento do banco mediante as queries enviadas pelos clientes, verificar os principais indicadores de performance e separar os SELECTs que estão demorando a retornar resultado. Mediante esta situação brevemente exposta de baixo desempenho, seguem algumas orientações de procedimentos a serem adotados para evitar esse problema.

O tempo de resposta de qualquer query é apenas um sintoma, não significa que determinada query está lenta. Para mensurar se realmente essa query é problemática seria necessário analisar: Ela está em concorrência? Em LOCK? Ou mal elaborada mesmo?

Tenha cautela na utilização de cursor. Este é um dos recursos que mais degradam o banco, pois todo momento que o cursor faz um FETCH, ele roda a query novamente. Agora imagine isso em tabelas de mais de um milhão de registros. Será mais trabalhoso pensar na lógica para substituir o cursor, mas isso pode ser feito utilizando outros recursos dentro da PROCEDURE, como expressões lógicas de loop e também trabalhando com os comandos SELECT...INTO, INSERT...INTO.

Percebendo que poderia melhorar o desempenho dos cursores a Microsoft implementou um tipo chamado INSENSITIVE, que leva o SELECT para o banco tempdb (que abriga tabelas temporárias), dando um ganho de performance. Mas mesmo assim é bom evitar o seu uso porque este cursor utiliza o tempdb, portanto, concorre com as tabelas temporárias existentes, usa a área de memória destinada a elas, e exige mais espaço físico do banco."