Quais são as suas optimizações sql mais comuns?

A minha lista favorita de dicas (explicada em detalhe aqui) é a seguinte

1. tente restringir o resultado das consultas, usando a cláusula onde.
2. tente restringir o resultado das consultas definido devolvendo apenas as colunas particulares da tabela, não todas as colunas da tabela.
3. Utilizar pontos de vista e procedimentos armazenados em vez de consultas pesadas.
4. sempre que possível, tente evitar usar cursores do servidor SQL.
5. Se precisar de devolver o total da tabela Contagem de linhas, você pode usar uma forma alternativa em vez da instrução Contagem de seleção (*).
6. tente usar restrições em vez de gatilhos, sempre que possível.
7. Utilizar as variáveis da tabela em vez das tabelas temporárias.
8. tente evitar a cláusula de ter, sempre que possível.
9. sempre que possível, tente evitar a utilização da cláusula distinta.
10. inclua definir um número na declaraà § à £ o nos seus procedimentos armazenados para parar a mensagem indicando o número de linhas afectadas por um T-SQL instrucao.
11. Use seleccionar as instruções com a palavra-chave de topo ou a opção Definir o número de linhas, se necessitar de devolver apenas as primeiras linhas.
12. Use a dica rápida da tabela numero_ rows se precisar de devolver rapidamente as linhas 'numero_ rows'.
13. tente usar todas as declarações da União em vez de união, sempre que possível.
14. não utilize dicas de optimização nas suas consultas.

De longe e acima: elaboração de índices de cobertura

Um índice de cobertura inclui todas as colunas que a consulta vai precisar, evitando assim a necessidade de fazer pesquisas sobre os resultados de uma pesquisa de índice. Isto evitará então que o sistema se sinta como um scan poderia ser mais rápido (o que é notavelmente rápido considerando o custo de pesquisas).

Ter um índice que permita uma junção de junção. Uma junção de junção é capaz de ocorrer ao juntar duas tabelas que são ordenado pelas condições de adesão. Mas, claro, ao dizer "tabela", nós realmente queremos dizer "índice", certo...

Também-remover funções escalares e usar funções de valor de tabela em vez disso... como as funções escalares não são capazes de ser simplificadas.

Também-colocando um índice único em uma coluna que você sabe ser única, permitindo que o otimizador de consulta use este conhecimento para fazer melhores escolhas de otimização. Também se aplica a restrições não nulas.

Também-usando uma colação binária quando comparando strings que estão em um caso conhecido, de modo que o sistema não tem que considerar as diferentes opções de caso.

Rob

'Cache' db output'. Evitar pressionar a base de dados parece ser uma otimização Prudente.

+1 memcached.

Indexem as chaves estrangeiras!

Talvez isto não seja uma optimização de sintaxe de consulta sql, mas sim uma optimização de armazenamento. Mas eu vejo que re-ocorrer o tempo todo e é um animal de estimação peeve.

Ainda não encontrei uma situação em que

SELECT Field1, Field2, (SELECT Count(*) FROM tblLinked WHERE tblLinked.Field3 = tblSource.Field3) AS TheTotal
FROM tblSource

Não é melhorado por uma junção esquerda a uma tabela derivada.

SELECT Field1, Field2, IsNull(Linked.TheTotal,0) AS TheTotal
FROM tblSource
LEFT JOIN (SELECT Field3, Count(*) AS TheTotal
    FROM tblLinked
    GROUP BY Field3) AS Linked ON tblSource.Field3 = Linked.Field3

2) Não ordenar os resultados no servidor a menos que o aplicativo consumidor não seja capaz de fazer isso sozinho. Isto aplica-se menos frequentemente a aplicações web, mas para aplicações desktop o PC cliente geralmente tem muita energia disponível e pode felizmente fazer uma espécie.

3) a utilização existe em vez de verificar o número de itens correspondentes.

A melhor otimização que já tive usando SQL foi realmente entender o que era necessário para ser feito os dados e remover ton de SQL da consulta.

A consulta mais rápida é a consulta que não tem de ser executada.

• Precisas mesmo de te juntar a todas aquelas mesas?

• Pode duas pequenas (simples) consultas fazer o trabalho melhor e mais rápido do que uma simples consulta?

• Se você combinar estas duas consultas em uma única consulta Pode correr mais rápido?

Reduzir os níveis de isolamento da transacção para contornar as fechaduras da tabela para consultas ao utilizador. Não o tempo todo, mas para a gui mostrar informações gerais, funciona muito bem.

Então eu colocaria a des-normalização que pode adicionar um pouco de desempenho para muitas bases de dados.

A optimização de consultas é a terceira e também ajuda muito. Eu uso o MySQL hoje em dia e o registro de consultas ajuda muito para otimização.

Memcached não é definitivamente common, though caching of some sort is a part of many websites at the scripting end (ASP.Net or PHP).

Certificando-se de que as mesas estão a ser unidas na ordem correcta.

As maiores optimizações que usei recentemente, onde é bastante simples.

Manter A maior parte da lógica de negócios o mais perto possível do servidor sql. Ou seja, manter o código de negócio na mesma máquina que o servidor sql. Deixe sua lógica de negócios retornar o mínimo possível código de volta para o cliente final.

Mantenha a sua consulta SQL tão 'curta quanto possível' como o Frost disse, use declarações de actualização simples sobre várias declarações.

Só usar as transacções quando for necessário eles

Criar tabelas temporárias para as ligações parciais para acelerar as ligações (não se esqueça de as indexar) {[[2]}

Li todas as respostas e não encontrei dicas de utilização de limites e desvios. É muito comum na paginação com links" prev "e" next". Mas rendering tal display pode consumir mais recursos do que todo o resto do site. Ao compensar itens de grande número, a consulta pode tornar-se muito lenta. Por isso, evitem estas perguntas.

• não conte os itens totais.
• Mostrar apenas os primeiros itens do número" n " (Por exemplo, apenas os 100 primeiros).

Existe um link do MySQL performance blog .

1. indexa a sua optimização mais comum
De normalizar as tabelas.
2. Remover restrições (apenas se souber o que está a fazer)

Evite o uso de funções de bordo como conversodate, stringreplace e assim nas suas vistas. Se você não pode se certificar de que os dados estão em um formato válido use procedimentos armazenados que executam reguallary para "limpar" os dados em suas tabelas relevantes.

Algumas dicas: Utilizar

delete from table where id>=1 and id<=3;

Em vez de

delete from table where id=1;
delete from table where id=2;
delete from table where id=3;

Também usar 'em' em vez de ' ou ' sintaxe

Não coloque restrições se não for necessário, pois as restrições irão adicionar um índice, quanto mais número de índices, mais tempo leva para a inserção de dados.