Vamos melhorar as suas queries?
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!
Links úteis
Aproveite e leia alguns posts importantes e que vão ajudar a melhorar suas queries:
5 coisas que você deve saber sobre o plano de execução das suas queries
Eventos bacanas
Essa semana vai ser bem legal, no dia 04/09/2018, terei o prazer de participar da Terça de Dados (puro amor!) , acho que qualquer DBA ficaria extremamente honrado com este convite e comigo não está sendo diferente, estou insuportável! rsrsrs
Falando sério, não percam! Vou conversar com o pessoal sobre o MongoDB 4.0 e as novidades desta versão (vai ser online) . Saiba mais neste link
Na quarta-feira (05/09/2018) eu estarei online com o pessoal do Caqui Coders (S2) Falando sobre os recursos do SQL Server 2017 que são bacanas para os desenvolvedores. Imperdível também!
Acompanhe a minha página do facebook para saber o link da transmissão.
No dia 18/09/2018 teremos o nosso meetup mensal do Databases-SP, onde eu vou falar um pouco sobre Modelagem de Dados e o Juliano Atanazio vai fazer uma introdução ao PostgreSQL. Vai ser aqui em SP, na FCNuvem pertinho do metrô. Inscreva-se neste link.
Novidades
No mês de novembro eu e a MVP Sulamita Dantas ministraremos um super curso de SQL Server em BH. Se você está interessado em participar deixe o seu email em SQL4.Fun
Em breve o nosso site WDB.Consulting estará no ar, e ficaremos imensamente felizes com a sua visita 🙂
Eu fiz uma enquete sobre qual poderia ser o nosso próximo assunto aqui no blog… E vem aí o PostgreSQL!!! Aguardem!