Início / dba / Perguntas / 58602
Accepted
Matthew
Asked: 2014-02-11 09:02:42 +0800 CST

Devo aninhar junções externas dependentes no SQL Server?

  • 772

Ouvi informações confusas sobre isso e espero uma opinião canônica ou especializada.

Se eu tiver vários LEFT OUTER JOINs , cada um dependente do último, é melhor aninhá-los?

Para um exemplo artificial, o JOINto MyParentdepende do JOINto MyChild: http://sqlfiddle.com/#!3/31022/5

SELECT
    {columns}
FROM
    MyGrandChild AS gc
LEFT OUTER JOIN
    MyChild AS c
        ON c.[Id] = gc.[ParentId]
LEFT OUTER JOIN
    MyParent AS p
        ON p.[id] = c.[ParentId]

insira a descrição da imagem aqui

Comparado com http://sqlfiddle.com/#!3/31022/7

SELECT
    {columns}
FROM
    MyGrandChild AS gc
LEFT OUTER JOIN
    (
    MyChild AS c            
    LEFT OUTER JOIN
        MyParent AS p
            ON p.[id] = c.[ParentId]
    )
    ON c.[Id] = gc.[ParentId]

insira a descrição da imagem aqui

Como mostrado acima, eles produzem planos de consulta diferentes em SS2k8

performance sql-server-2008-r2

2 respostas

  1. Best Answer

    Esta não é absolutamente uma resposta canônica, mas notei que, para os planos de consulta de loops aninhados mostrados no SQL Fiddle, era possível aplicar o plano da Consulta 2 à Consulta 1 com o uso da USE PLANdica, mas a tentativa da operação reversa falha com

    O processador de consulta não pôde produzir o plano de consulta porque a dica USE PLAN contém um plano que não pôde ser verificado como válido para a consulta. Remova ou substitua a dica USE PLAN. Para obter a melhor probabilidade de imposição de plano bem-sucedida, verifique se o plano fornecido na dica USE PLAN é gerado automaticamente pelo SQL Server para a mesma consulta.

    Desativar a regra de transformação do otimizador ReorderLOJN impede que a dica de plano bem-sucedida anterior também seja bem-sucedida.

    Experimentar com maiores quantidades de dados mostra que o SQL Server certamente também é capaz de (A LOJ B) LOJ Cse transformar A LOJ (B LOJ C)naturalmente, mas não vi nenhuma evidência de que o inverso seja verdadeiro.

    Um caso muito artificial em que a primeira consulta tem um desempenho melhor que o segundo é

    DROP TABLE  MyGrandChild , MyChild,  MyParent

CREATE TABLE MyParent
(Id int)

CREATE TABLE MyChild
(Id int PRIMARY KEY
,ParentId int,
Filler char(8000) NULL)

CREATE TABLE MyGrandChild
(Id int
,ParentId int)

INSERT INTO MyChild
                      (Id, ParentId)
SELECT TOP (100000) ROW_NUMBER() OVER (ORDER BY @@SPID),
                     ROW_NUMBER() OVER (ORDER BY @@SPID)    
FROM master..spt_values  v1, master..spt_values                  

INSERT INTO MyGrandChild
                      (Id, ParentId)
OUTPUT INSERTED.Id INTO MyParent
SELECT TOP (3000) Id, Id AS ParentId
FROM MyChild
ORDER BY Id

SET STATISTICS IO ON;
SET STATISTICS TIME ON;

SELECT gc.Id       AS gcId,
       gc.ParentId AS gcpId,
       c.Id        AS cId,
       c.ParentId  AS cpId,
       p.Id        AS pId
FROM   MyGrandChild AS gc
       LEFT OUTER JOIN MyChild AS c
         ON c.[Id] = gc.[ParentId]
       LEFT OUTER JOIN MyParent AS p
         ON p.[Id] = c.[ParentId]

SELECT gc.Id       AS gcId,
       gc.ParentId AS gcpId,
       c.Id        AS cId,
       c.ParentId  AS cpId,
       p.Id        AS pId
FROM   MyGrandChild AS gc
       LEFT OUTER JOIN( MyChild AS c
                        LEFT OUTER JOIN MyParent AS p
                          ON p.[Id] = c.[ParentId])
         ON c.[Id] = gc.[ParentId]

    Que dá planos

    insira a descrição da imagem aqui

    Para mim, a Consulta 1 teve um tempo decorrido de 108 ms contra 1.163 ms para a Consulta 2.

    Consulta 1

    Table 'Worktable'. Scan count 0, logical reads 0 
Table 'MyChild'. Scan count 0, logical reads 9196
Table 'MyGrandChild'. Scan count 1, logical reads 7
Table 'MyParent'. Scan count 1, logical reads 5

    Consulta 2

    Table 'MyParent'. Scan count 1, logical reads 15000
Table 'MyChild'. Scan count 0, logical reads 9000 
Table 'MyGrandChild'. Scan count 1, logical reads 7

    Portanto, pode-se presumir provisoriamente que a primeira sintaxe ("desaninhada") é potencialmente benéfica, pois permite que mais pedidos de junção em potencial sejam considerados, mas não fiz testes exaustivos o suficiente para ter muita confiança nisso como regra geral.

    Pode muito bem ser inteiramente possível criar exemplos contrários em que a Consulta 2 tenha um desempenho melhor. Experimente os dois e veja os planos de execução.

    • 3

  2. não existe tal tipo de JOIN chamado "Nested Join". é uma outra variação de escrita que o JOIN pode ser para fins de conveniência de legibilidade. você pode vê-los como "Subconsultas" apenas para fins de compreensão.

    se você está mais preocupado com a legibilidade do código, então minha opinião é que é uma escolha individual com o que eles podem ser conferidos.

    E se você estiver preocupado com o desempenho da consulta e a dica "Force JOIN ORDER" não for usada na consulta, não importa se a consulta for escrita com "Nested Join" ou All "Outer Join". O servidor SQL cria o pedido com base no custo de unir duas tabelas e/ou resultado. O SQL Server faz o JOIN apenas entre dois conjuntos de dados por vez.

    na verdade, imagine que na segunda forma "nested join" se o SQL server decidir fazer a segunda parte, "MyChild AS c LEFT OUTER JOIN MyParent AS p ON p.[id] = c.[ParentId]" e essas tabelas acontecerem para ter linhas que serão descartadas em NEXT LEFT JOIN. nesse caso, o servidor SQL gastou recursos desnecessários fazendo o OUTER JOIN desses dois e passando esse resultado para o próximo JOIN.

    você também pode ver perguntas semelhantes feitas e respondidas adequadamente aqui. Compreendendo a sintaxe de 'junção aninhada'

    • -1

relate perguntas