Aqui está a lista de coisas que eu sempre dou para alguém que me pergunta sobre otimização.
Nós usamos principalmente o Sybase, mas a maioria dos conselhos se aplica a todos.
O SQL Server, por exemplo, vem com uma série de bits de monitoramento / ajuste de desempenho, mas se você não tiver nada parecido (e talvez até mesmo se tiver), eu consideraria o seguinte ...
99% dos problemas Eu vi são causados por colocar muitas tabelas em uma junção . A correção para isso é fazer metade da junção (com algumas das tabelas) e armazenar em cache os resultados em uma tabela temporária. Em seguida, faça o restante da consulta juntando-se a essa tabela temporária.
Lista de verificação de otimização de consulta
- Execute UPDATE STATISTICS nas tabelas subjacentes
- Muitos sistemas executam isso como um trabalho semanal agendado
- Excluir registros de tabelas subjacentes (possivelmente arquivar os registros excluídos)
- Considere fazer isso automaticamente uma vez por dia ou uma vez por semana.
- Reconstruir índices
- Reconstruir tabelas (saída/entrada de dados bcp)
- Dump/recarregue o banco de dados (drástico, mas pode corrigir a corrupção)
- Crie um índice novo e mais apropriado
- Execute o DBCC para ver se há uma possível corrupção no banco de dados
- Bloqueios / Impasses
- Certifique-se de que nenhum outro processo seja executado no banco de dados
- Especialmente DBCC
- Você está usando bloqueio no nível de linha ou página?
- Bloqueie as tabelas exclusivamente antes de iniciar a consulta
- Verifique se todos os processos estão acessando tabelas na mesma ordem
- Certifique-se de que nenhum outro processo seja executado no banco de dados
- Os índices estão sendo usados adequadamente?
- As junções só usarão o índice se ambas as expressões forem exatamente do mesmo tipo de dados
- O índice só será usado se o(s) primeiro(s) campo(s) do índice corresponderem à consulta
- Os índices agrupados são usados quando apropriado?
- dados de intervalo
- Campo WHERE entre valor1 e valor2
- Pequenas junções são boas junções
- Por padrão, o otimizador considerará apenas as quatro tabelas por vez.
- Isso significa que em junções com mais de 4 tabelas, há uma boa chance de escolher um plano de consulta não ideal
- Divida a união
- Você pode desfazer a junção?
- Pré-selecione chaves estrangeiras em uma tabela temporária
- Faça metade da junção e coloque os resultados em uma tabela temporária
- Você está usando o tipo certo de tabela temporária?
#temptabelas podem ter um desempenho muito melhor do que@tablevariáveis com grandes volumes (milhares de linhas).
- Manter Tabelas de Resumo
- Crie com acionadores nas tabelas subjacentes
- Construa diariamente/por hora/etc.
- Criar ad hoc
- Crie de forma incremental ou desmonte/reconstrua
- Veja qual é o plano de consulta com SET SHOWPLAN ON
- Veja o que realmente está acontecendo com SET STATS IO ON
- Forçar um índice usando o pragma:(index:myindex)
- Forçar a ordem da tabela usando SET FORCEPLAN ON
- Sniffing de parâmetros:
- Divida o procedimento armazenado em 2
- chamar proc2 de proc1
- permite que o otimizador escolha o índice em proc2 se @parameter foi alterado por proc1
- Você pode melhorar seu hardware?
- Que horas você está correndo? Existe um horário mais tranquilo?
- O servidor de replicação (ou outro processo ininterrupto) está em execução? Você pode suspendê-lo? Execute-o, por exemplo. de hora em hora?
