Quando falamos em desempenho de banco de dados temos 2 momentos, o da criação e o da manutenção.

O momento da criação eu acho mais fácil, por que ainda não temos dados para nos preocupar, e por isso podemos dedicar um pouco mais de atenção ao modelo do banco de dados.

Eu sempre brinco que nós devemos começar a melhoria de desempenho de uma aplicação quando começamos a criar o banco de dados. Sim! Tuning começa na criação do BD, pelo simples fato de ser mais barato criar um banco de dados da forma correta, do que fazer correções posteriores.

Então a primeira dica para que suas aplicações tenham sucesso é faça certo!

E neste post eu quero compartilhar algumas boas práticas com vocês:

1 – Escolha o tipo de dados correto.

• Escolha o tipo de dados correto. Se você vai criar uma tabela que possui uma coluna com a sigla do estado brasileiro (por exemplo), sabemos que este atributo tem duas posições, neste caso o data type mais adequado é o char(2). Usar o data type incorreto, pode consumir mais espaço e pode causar conversões implícitas e explicitas. Que consomem recursos desnecessariamente e podem levar o otimizador de consultas a escolher planos pouco eficientes

2- Use tipo de dados unicode somente quando necessário.

• Os tipos de dados Unicode, como nchar e nvarchar, usam duas vezes mais espaço de armazenamento em comparação com tipos de dados ASCII como char e varchar.

3- Modele o seu banco de dados!

• Parece besteira? Mas quando você cria uma representação visual fica mais fácil verificar se os dados terão consistência. E eu não estou bancando a AD super rigorosa. Mas pense no seguinte cenário, uma equipe com vários desenvolvedores criando um banco de dados, talvez fique impossível analisar se o fluxo da informação está correto e se as informações estão consistentes utilizando somente os scripts.

4- Utilize o recursos do SGBD.

• Evite deixar para a sua aplicação validar algumas regras de qualidade que podem ser garantidas com recursos nativos e declarativos do SGBD. Por exemplo, se uma coluna aceita somente 3 valores crie uma check constraint para validar os valores. Se a coluna tem um valor default, use o objeto default. Digo isso porque se existem N aplicações desenvolvidas por equipes diferentes usando o mesmo BD, e uma das equipes não criou o código para garantir as regras de qualidade, o banco de dados poderá ficar inconsistente.

5- Pense bem nos seus índices…

• Se a sua base de dados ainda está vazia, então tenha em mente que os testes de desempenho podem indicar a necessidade de criar índices. Contudo, vale a regrinha básica… Se a coluna tem muitas atualizações utilizá-la em um índice pode degradar o desempenho ao invés de melhorar.

6- Na clausula WHERE evite negações, funções e conversões, porque podem ignorar os índices.

7- WHERE <> HAVING !!!

• Use a cláusula HAVING para o que ela se propõe, filtrar operações de agregação.

8- SELECT * é do mal!

• Se não é para testes, não use o SELECT * , pois o SGBD “gastará” um tempo de processamento para buscar quais são todos as colunas da(s) tabela(s) especificada(s) na cláusula FROM.

9- Cursor é quase sempre do mal!

• Só use em últimos casos! Eles consomem muitos recursos e são mais lentos do que consultas que processam lotes de dados. Se você precisa processar linha por linha, então use a sua aplicação.
• CURSOR é só se você realmente não tem outra alternativa, se serão executados muito esporadicamente, fora do horário de pico, você já pediu ajuda para os DBAs e para o restante do seu time, resumindo, muito cuidado!

10 – Triggers podem ser fofas!

• Evite ações longas em triggers, por que podem fazer com que os bloqueios sejam mantidos por mais tempo. Mantenha o código da trigger tão pequeno e eficiente quanto possível.

11 – Avalie o plano de execução da consulta

• No SQL Query Analyzer, ative a opção Exibir plano de execução e execute sua consulta contra uma carga significativa de dados para ver o plano criado pelo otimizador.
• Avalie este plano e depois identifique o que pode ser melhorado. Por exemplo, as operações mais demoradas. Compreender o plano de execução é um passo importante para otimizar uma consulta. Tal como acontece com a indexação, leva tempo e conhecimento do seu sistema para poder identificar o melhor plano.

12 – Sempre prefira usar o namespace (owner / esquema) dos objetos (nome da tabela, procedures, etc.) .

• Se o nome do owner/esquema não for fornecido, a engine do SQL Server tentará encontrar o objeto em todos os esquemas , ou seja, uma busca desnecessária.

13 – Não use o prefixo sp_ no nome das stored procedures.

• Quando o procedimento armazenado é nomeado  sp_ ou  SP_, o SQL Server sempre verifica no banco de dados master mesmo se o nome do owner/ esquema for fornecido. Escolher um nome sem SP_  para as suas stored procedures evita essa verificação desnecessária.

Conclusão

Melhorar as suas queries pode ser mais fácil do que parece. E eu espero que você escreva queries cada vez mais eficazes e eficientes!