Pergunta

Eu tenho uma consulta relativamente simples junção de duas tabelas. O "Onde" critérios pode ser expresso nos critérios de juntar ou como uma cláusula onde. Eu estou querendo saber o que é mais eficiente.

Consulta é encontrar vendas max para um vendedor desde o início do tempo, até que foram promovidos.

Caso 1

select salesman.salesmanid, max(sales.quantity)
from salesman
inner join sales  on salesman.salesmanid =sales.salesmanid 
                  and sales.salesdate < salesman.promotiondate
group by salesman.salesmanid 

Caso 2

select salesman.salesmanid, max(sales.quantity)
from salesman
inner join sales  on salesman.salesmanid =sales.salesmanid 
where sales.salesdate < salesman.promotiondate
group by salesman.salesmanid 

Nota Caso 1 carece de uma cláusula onde completamente

RDBMS é Sql Server 2005

Editar Se a segunda parte dos critérios de união ou a cláusula onde foi sales.salesdate

Foi útil?

Solução

Eu não usaria desempenho como o fator decisivo aqui -. E muito honestamente, eu não acho que haja qualquer diferença de desempenho mensurável entre esses dois casos, realmente

Eu sempre usar caso # 2 - por quê? Porque na minha opinião, você só deve colocar os critérios reais que estabelecem a junção entre as duas tabelas na cláusula JOIN -. Tudo o resto pertence na cláusula WHERE

apenas uma questão de manter as coisas limpas e colocar as coisas onde elas pertencem, IMO.

Obviamente, há casos com LEFT OUTER joins onde a colocação dos critérios faz diferença em termos do que resultados se voltou -. Nesses casos seriam excluídos da minha recomendação, é claro

Marc

Outras dicas

Você pode executar o estimador de plano de execução e SQL Profiler para ver como eles se comportam uns contra os outros.

No entanto, eles são semanticamente o mesmo debaixo do capô de acordo com esta MVP de SQL Server:

http://www.eggheadcafe.com/conversation.aspx?messageid = 29145383 & threadid = 29145379

Eu prefiro ter quaisquer critérios codificados duros na junção. Isso torna o SQL muito mais legível e portátil.

Legibilidade: Você pode ver exatamente o que os dados que você vai conseguir, porque todos os critérios de mesa está escrito ali na junção. Em declarações grandes, os critérios podem ser enterrado dentro de 50 outras expressões e é facilmente perdido.

Portabilidade: Você pode simplesmente copiar um pedaço de cláusula FROM e colá-lo em outro lugar. Isso dá a junta e os critérios que você precisa para ir com ele. Se você usar sempre que os critérios de quando juntar essas duas tabelas, em seguida, colocá-lo na junção é o mais lógico.

Por exemplo:

FROM
table1 t1
JOIN table2 t2_ABC ON
  t1.c1 = t2_ABC.c1 AND
  t2_ABC.c2 = 'ABC'

Se você precisa para obter uma segunda coluna para fora da tabela 2 que você acabou de copiar esse bloco no bloco de notas, pesquisar / repalce "ABC" e pronto e todo novo bloco de código pronto para colar novamente.

adicionais: É também mais fácil para a mudança entre um interior e exterior entrar sem ter que se preocupar com qualquer critérios que podem ser flutuando na cláusula WHERE.

I reservar a cláusula WHERE estritamente para critérios de tempo de execução, sempre que possível.

Como para a eficiência: Se você está se referindo a velocidade excecution, em seguida, como todos os outros declarou, é redundante. Se você está se referindo a depuração mais fácil e reutilização, então eu prefiro a opção 1.

Uma coisa que eu quero dizer, finalmente, como I notificado, antes disso .. Ambas as formas podem dar o mesmo desempenho ou utilizando os critérios em Onde cláusula pode ser um pouco mais rápido como encontrado em algumas respostas ..

Mas eu identificada uma diferença, você pode usar para suas necessidades lógicas ..

  1. Usando os critérios em ON cláusula não filtro / ignorar as linhas para selecionar vez a juntar-se colunas iria ser nulo com base nas condições

  2. Usando os critérios em Onde cláusula pode filtrar / ignorar as linhas com os resultados completos

Eu não acho que você vai encontrar uma resposta finita para um presente que se aplica a todos os casos. O 2 nem sempre são intercambiáveis ??- uma vez que para algumas consultas (alguns esquerda junta-se) você vai chegar a resultados diferentes, colocando os critérios na ONDE vs linha De

.

No seu caso, você deve avaliar ambas as consultas. Em SSMS, você pode visualizar os planos de execução estimados e reais de ambos os consultas - o que seria um bom primeiro passo para determinar o que é mais ideal. Você também pode ver a hora e IO para cada (estatísticas set momento, estatísticas set io on) - e que também lhe dará informações para tomar sua decisão

.

No caso das consultas em sua pergunta - eu aposto que os dois vão sair com o mesmo plano de consulta - por isso, neste caso, pode ser que não importa, mas em outros pode potencialmente produzir planos diferentes <. / p>

Tente isto para ver a diferença entre o 2 ...

SET STATISTICS IO ON
SET STATISTICS TIME ON

select salesman.salesmanid, 
       max(sales.quantity)
from   salesmaninner join sales on salesman.salesmanid =sales.salesmanid
       and sales.salesdate < salesman.promotiondate
group by salesman.salesmanid

select salesman.salesmanid, 
       max(sales.quantity)
from   salesmaninner join sales on salesman.salesmanid = sales.salesmanid 
where  sales.salesdate < salesman.promotiondate
group by salesman.salesmanid

SET STATISTICS TIME OFF
SET STATISTICS IO OFF

Pode parecer frívolo, mas a resposta é qualquer consulta para a qual o analisador consulta produz o plano mais eficiente.

Para minha mente, eles parecem ser equivalentes, de modo que o analisador de consulta pode muito bem produzir planos idênticos, mas você teria de teste.

Nem é mais eficiente, usando o ONDE método é considerado a maneira antiga de fazer isso ( http://msdn.microsoft.com/en-us/library/ms190014.aspx ). Você pode olhar para o plano de execução e ver o que eles fazem a mesma coisa.

Familiarize-se com o plano de execução estimado no SQL Management Studio !! Como já foi dito, você está à mercê do analisador não importa o que você fizer isso confiar em suas estimativas. Eu acho que os dois que forneceu iria produzir exatamente o mesmo plano.

Se é uma tentativa de mudar a cultura de desenvolvimento, escolher o que lhe dá um plano melhor; para os que são idênticos, siga a cultura

Eu já comentou isso em outros lugares "eficiência" como este (é tanto sincero e sarcástico) -. Se este é o lugar onde seus gargalos residem, em seguida, alta e cinco para você e sua equipe

Caso 1 (critérios do JOIN) é melhor para encapsulamento, e aumentou encapsulamento é normalmente uma coisa boa: diminuição copiar / colar omissões para outra consulta, diminuiu os erros se mais tarde convertido em LEFT JOIN, e aumento da legibilidade (juntamente coisas relacionadas e menos "ruído" na cláusula WHERE). Neste caso, a cláusula WHERE só captura principais critérios de mesa ou critérios que se estende por várias tabelas.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top