desempenho da consulta SQL
neste caso específico, você não notará uma grande diferença porque 30.000 linhas não são muito difíceis de processar pelo banco de dados. No entanto, se você estivesse falando de centenas de milhões de linhas ou mais, veria uma melhoria notável agregando antes de ingressar. Ao fazer isso, certifique — se de que o que você está fazendo é logicamente consistente-você deve se preocupar com a precisão do seu trabalho antes de se preocupar com a velocidade de execução.
13 dicas de desempenho de consulta
lembre-se de prefixar nomes de objetos (ou seja, tabela, procedimento armazenado, visualização) com seu nome de proprietário / esquema.
razão: se o nome do proprietário / esquema não for fornecido, o mecanismo do SQL Server tenta encontrá-lo em todos os esquemas até que o objeto o encontre. O SQL Server engine não pesquisará a tabela fora de seu proprietário / esquema se o nome do proprietário/esquema for fornecido.
o operador *
não use o operador * em suas instruções SELECT. Em vez disso, use nomes de colunas.
razão: o SQL Server verifica todos os nomes das colunas e substitui o * por todos os nomes das colunas da(S) tabela (s) na instrução SQL SELECT. Fornecer nomes de coluna evita essa pesquisa e substituição e melhora o desempenho.
colunas anuláveis
evite usar NOT in ao comparar com colunas anuláveis. O uso não existe em vez disso.
razão: quando NOT IN é usado na consulta (mesmo que a consulta não retorne linhas com os valores nulos), o SQL Server verificará cada resultado para ver se é nulo ou não. Usar não existe não fará a comparação com nulos. Além disso, NOT EXISTS retorna apenas dois estados (verdadeiro ou falso), enquanto NOT in pode retornar até três estados (verdadeiro, falso, nulo) e pode não lhe dar o resultado que você estava esperando.
variáveis de tabela e junções
evite usar variáveis de tabela em junções. Use tabelas temporárias, CTEs (expressões de tabela comuns) ou tabelas derivadas em junções.
razão: embora as variáveis de tabela sejam muito rápidas e eficientes em muitas situações, o mecanismo do SQL Server o vê como uma única linha. Devido a esse motivo, o SQL produzirá um plano de execução que terá um desempenho horrível quando usado em junções.
nomes de procedimentos armazenados
não inicie o nome do procedimento armazenado com sp_.
motivo: quando o procedimento armazenado é chamado sp_ ou SP_, o SQL Server sempre verifica no banco de dados do sistema/mestre, mesmo que o nome do proprietário/esquema seja fornecido. Fornecer um nome sem SP_ para um procedimento armazenado evita essa verificação desnecessária no banco de dados do sistema/mestre no SQL Server.
Use Set NOCOUNT em
use SET NOCOUNT em com operações DML.
razão: ao realizar operações DML (ou seja, Inserir, Excluir, selecionar e atualizar), o SQL Server sempre retorna o número de linhas afetadas. Em consultas complexas com muitas junções, isso se torna um grande problema de desempenho. Usar Set NOCOUNT on melhorará o desempenho porque não acompanhará o número de linhas afetadas.
evite usar GROUP BY, ORDER BY e DISTINCT
evite usar GROUP BY, ORDER BY e DISTINCT sempre que possível.
razão: ao usar GROUP BY, ORDER BY ou DISTINCT, o SQL Server engine cria uma tabela de trabalho e coloca os dados na tabela de trabalho. Depois disso, ele organiza esses dados na tabela de trabalho conforme solicitado pela consulta e, em seguida, retorna o resultado final.
verifique os índices
deve haver índices em todos os campos usados nas partes WHERE E JOIN da instrução SQL.
razão: quando os campos não são indexados, o SQL Server normalmente fará uma verificação completa da tabela e isso pode reduzir o desempenho. A menos que a tabela seja muito pequena, uma varredura de tabela tende a produzir o pior desempenho de todos os tipos de leituras de banco de dados.
Use o mesmo tipo de dados nas Cláusulas JOIN e WHERE
isso é mais fácil de dizer do que fazer, dependendo de suas permissões para fazer alterações no esquema.
razão: ao juntar ou comparar dois campos com tipos de dados diferentes, o SQL deve fazer uma conversão instantânea do campo antes que ele possa fazer uma comparação, mesmo que os campos sejam indexados. Se os tipos de dados incompatíveis forem inevitáveis, tente converter o tipo de dados maior para o tipo de dados menor sempre que possível.
evite usar campos calculados em JOIN e onde cláusulas
isso pode ser feito criando um campo com os valores calculados usados na junção na tabela. Abaixar.