É este dica de junção perigoso?

Question

Um colega me pediu para olhar para indexação em algumas tabelas porque a sua consulta estava correndo muito longo. Mais de uma hora.

select count(1)
from databaseA.dbo.table1
inner join databaseA.dbo.table2 on (table1.key = table2.key)
inner join databaseB.dbo.table3 on (table1.key = table3.key)

Observe os diferentes bancos de dados. Este estava sendo executado a partir de DatabaseB

As Tabelas 1 e 2 foram mais de 2 milhões de registros de comprimento. Table3 tinha uma dúzia de registros ou assim.

Eu olhei para o plano de consulta e o otimizador decidiu fazer índice de loop aninhado busca em tabelas 1 e 2 com Tabela3 como a tabela condução!

Minha primeira suposição era de que as estatísticas ficaram gravemente desordenado em Tables1 & 2, mas antes de estatísticas de atualização Eu tentei adicionar uma dica de junção assim:

select count(1)
from databaseA.dbo.table1
inner HASH join databaseA.dbo.table2 on (table1.key = table2.key)
inner join databaseB.dbo.table3 on (table1.key = table3.key)

Os resultados retornados em 15 segundos.

Desde que eu estava em curto tempo, eu passei os resultados de volta para ele, mas eu estou preocupado que isso pode resultar em problemas no caminho.

Eu deveria rever as estatísticas emitir e resolver o problema dessa maneira? Poderia o plano de consulta ruim ter resultado da junção sendo de uma bases de dados separadas?

Alguém pode me oferecer algumas idéias baseado em sua experiência?

Answer 1

Eu suspeito as estatísticas em primeiro lugar.

Como você sem dúvida sabe, Junte dicas deve ser evitada em 99% dos casos e usado somente quando você tem a prova de que eles são absolutamente necessários.

Answer 2

Verifique as estatísticas, e indexação na mesa primeiro. dicas de índice pode causar problemas. Se os dados nas tabelas muda o otimizador não será capaz de escolher um plano mais eficiente desde que você foi obrigado a usar sempre um hash.

Answer 3

Não seria um loop aninhado ser o mais apropriado? Pegue os 12 registros da Tabela 3, jogo aos 12 registros na Tabela 1, jogo para 12 registros na Tabela 2.

Caso contrário, seu hash iria impor ordenação, bem como - o que significa que tinha de hash 1 milhão de registros da Tabela 1 e Tabela 2, em seguida, juntar-se aos 12 registros na Tabela 3

.

Eu olhava para estatísticas para ambos os planos -. E eu suspeito que o loop juntar-se é realmente mais eficiente, mas foi bloqueado ou a sua junção de hash estava se aproveitando de dados em cache

Mas - Sim. - em geral, juntar sugestões são um último recurso

Answer 4

Uma consulta de execução lenta envolvendo servidores vinculados pode ter a ver com o agrupamento. Veja aqui algumas informações: http://blogs.msdn.com/psssql/archive/2008/02/14/how-it-works-linked-servers-and-collation-compatibility.aspx O hash unir forças dica do SortOrder, de modo que explica o ganho de desempenho.

Veja como definir as opções:

EXEC master.dbo.sp_serveroption 
    @server=N'databaseA', 
    @optname=N'collation compatible', 
    @optvalue=N'true'

EXEC master.dbo.sp_serveroption 
    @server=N'databaseA', 
    @optname=N'use remote collation', 
    @optvalue=N'false'

-Edoode