Vou deixar algumas dicas que utilizo em minhas consultas:
Evite:
- SELECT * FROM TABELA, pois cria uma sobrecarga maior sobre a tabela, entrada/saída e largura de banda na rede do servidor. É melhor especificar os campos que irá utilizar.
- Cursores.
- Evite funções como LOWER ou UPPER para comparar texto, pois não são necessárias para o SQL.
- Evite executar cálculos matemáticos na cláusula WHERE. Se possível, envie esses cálculos já prontos da aplicação.
- Evite usar gatilhos como as TRIGGERs. Use-os apenas como último recurso.
Evite:
- SELECT * FROM TABELA, pois cria uma sobrecarga maior sobre a tabela, entrada/saída e largura de banda na rede do servidor. É melhor especificar os campos que irá utilizar.
- Cursores.
- Evite funções como LOWER ou UPPER para comparar texto, pois não são necessárias para o SQL.
- Evite executar cálculos matemáticos na cláusula WHERE. Se possível, envie esses cálculos já prontos da aplicação.
- Evite usar gatilhos como as TRIGGERs. Use-os apenas como último recurso.
- Evite usar funções ou não exagere no uso delas.
Prefira:
- Essa dica é muito importante,seguir a ordem de performance dos operadores nos filtros WHERE :
1º (=),2º (>, >=, <, <=),3º(LIKE),4º(<>).
- As consultas com a condição WHERE conectadas por operadores AND são avaliadas da esquerda para a direita. Então, caso uma das operações seja falsa, não importam as demais: a linha será rejeitada. Logo, é melhor colocar as colunas com maior probabilidade de serem falsas no começo do WHERE e poupar processamento nesses casos.
- As consultas com a condição WHERE conectadas por operadores AND são avaliadas da esquerda para a direita. Então, caso uma das operações seja falsa, não importam as demais: a linha será rejeitada. Logo, é melhor colocar as colunas com maior probabilidade de serem falsas no começo do WHERE e poupar processamento nesses casos.
- Prefira manter a integridade do banco com CONSTRAINTs.
- As colunas que que mais utiliza nas condições do WHERE e JOIN , índices nas tabelas.
- Para apagar todas as linhas de uma tabela, prefira o comando TRUNCATE TABLE ao invés de DELETE.
- Para apagar todas as linhas de uma tabela, prefira o comando TRUNCATE TABLE ao invés de DELETE.
- Quando o retorno for de muitos registros utilize o comando TOP (TOP 1, TOP 10, TOP 1000 etc...).
- Tente trocar o operador IN ou NOT IN por EXISTS ou NOT EXISTS, quando for possível, pois os operadores IN criam uma sobrecarga maior no banco de dados.
- Substituir o IN por BETWEEN.
- Às vezes é melhor usar várias consultas unidas com UNION ALL do que uma consulta com vários OR em sua cláusula WHERE.
- Quando existir uma cláusula HAVING, é melhor fazer a maior parte da filtragem possível na WHERE e deixar a HAVING mais enxuta possível.
- Caso haja a necessidade de retornar alguns dados da consulta o mais rápido possível, mesmo que não seja o resultado total, pode-se usar a opção FAST.
- Se possível, prefira usar UNION ALL ao invés de UNION. O UNION elimina as duplicatas, mas isso exige um processamento maior.
- Prefira usar tabelas variáveis do que tabelas temporárias.
- Se uma tabela tem uma chave primária IDENTITY e sofre muitas inserções simultâneas, faça seu índice na chave primária ser não-clusterizado para evitar gargalos de performance.
- Toda tabela relacional deveria ter uma chave primária. Salvo exceções, claro, como modelagens de data warehouses e semelhantes.
- Use (NOLOCK) após os nomes de tabelas, até mesmo nos Joins. É importante, pois alguns processos são feitos por transações que bloqueiam as tabelas até serem finalizados, com (NOLOCK) as tabelas não são travadas, impedido uma lentidão em sua consulta.
- Prefira o LIKE ao invés do SUBSTRING.
-Tente acessar tabelas grandes apenas 1 vez na sua consulta
- Para lógicas muito extensas, prefira STORED PROCEDUREs.
Atente-se:
- Muitos problemas de performance que vi em bancos de dados estavam relacionados a produtos cartesianos. Ocorrem quando fazemos algo de errado nos relacionamentos dos Joins ou Where.
Quem tiver algo a acrescentar ou a corrigir deixe um comentário aqui !!!
Fonte de pesquisa:
http://www.linhadecodigo.com.br/artigo/62/aumente-a-performance-do-sql-server.aspx
http://b.erickmendonca.com.br/post/48801937309/melhorando-a-performance-de-consultas-no-sql-server
http://www.infoworld.com/d/data-management/7-performance-tips-faster-sql-queries-262
- Use (NOLOCK) após os nomes de tabelas, até mesmo nos Joins. É importante, pois alguns processos são feitos por transações que bloqueiam as tabelas até serem finalizados, com (NOLOCK) as tabelas não são travadas, impedido uma lentidão em sua consulta.
- Prefira o LIKE ao invés do SUBSTRING.
-Tente acessar tabelas grandes apenas 1 vez na sua consulta
- Para lógicas muito extensas, prefira STORED PROCEDUREs.
Atente-se:
- Muitos problemas de performance que vi em bancos de dados estavam relacionados a produtos cartesianos. Ocorrem quando fazemos algo de errado nos relacionamentos dos Joins ou Where.
- Verifique se as VIEWs, são realmente úteis. Caso não sejam, prefira consultar diretamente as tabelas.
- Em consultas muito frequentes, tente utilizar STORED PROCEDURE. Normalmente a performance melhora isso se deve à otimizações no plano de execução dos procedimentos armazenados.
- Verifique se o servidor não está com pouco espaço em disco. Recomendo pelo menos sempre 30% do disco livre.
Fonte de pesquisa:
http://www.linhadecodigo.com.br/artigo/62/aumente-a-performance-do-sql-server.aspx
http://b.erickmendonca.com.br/post/48801937309/melhorando-a-performance-de-consultas-no-sql-server
http://www.infoworld.com/d/data-management/7-performance-tips-faster-sql-queries-262