Início / dba / Perguntas / 207957
Accepted
motoDrizzt
Asked: 2018-05-27 23:51:47 +0800 CST

Curto-circuito em JOIN

  • 772

Já procurei em todos os lugares mas não consegui encontrar nada a respeito, parece que todo mundo está preocupado apenas com WHERE e CASE. (e não tenho um SQL Server disponível para verificar por mim mesmo)

Então, uma pergunta simples: o JOIN de curto-circuito do SQL Server é baseado na condição JOIN? Se eu escrever:

TableA LEFT OUTER JOIN TableB ON 1=0 AND TableA.ID = TableB.A_ID

O SQL Server ignorará a junção?

Editar

Ok, alguém apontou corretamente que isso é resolvido em tempo de compilação, então é melhor eu expandir a questão.

O acima foi apenas um exemplo, mas acabou sendo ruim. O que eu queria saber é se o SQL Server causa um curto-circuito em um JOIN quando essa condição acontece em tempo de execução, como consequência de um @parameter passado para um procedimento armazenado.

Estou perguntando porque tenho certeza de ter usado algo assim nos anos, mas queria ter 100% de certeza antes de falar sobre isso com alguns colegas. Então, o SQL Server fará um curto-circuito nisso, então:

TableA LEFT OUTER JOIN TableB ON @parameter IS NOT NULL AND TableA.ID = TableB.A_ID

se estiver dentro de um SP e for chamado com @parameter definido como NULL? Fará alguma diferença se o procedimento de armazenamento for COM RECOMPILAR?

sql-server t-sql

2 respostas

  1. DB<>fiddle e outros serviços online permitem que você teste diferentes DBMS sem precisar instalá-los localmente. Como mostrado em:

    https://dbfiddle.uk/?rdbms=sqlserver_2017&fiddle=7692d5abba854bdc57d90c95335014c0

    Não há acesso à tabela B.

    Você pode encontrar o seguinte artigo de interesse de Lukas Eder, ele compara otimizações algébricas para diferentes DBMS:

    https://blog.jooq.org/2017/09/28/10-cool-sql-optimisations-that-do-not-depend-on-the-cost-model/

    • 6
  2. Best Answer
    1. O SQL Server fará um curto-circuito nisso, então: TableA LEFT OUTER JOIN TableB ON @parameter IS NOT NULL AND TableA.ID = TableB.A_IDse estiver dentro de um SP e for chamado com @parameter definido como NULL?
    2. Fará alguma diferença se o procedimento de armazenamento forWITH RECOMPILE

    Configuração de dados

    CREATE TABLE TableA(ID INT PRIMARY KEY);
CREATE TABLE TableB(A_ID INT);

INSERT INTO TableA VALUES (1), (2), (3);

INSERT INTO TableB VALUES (1), (1), (1), (1), (1), (1), (2), (3);

    Processo armazenado

    CREATE PROC P1 @parameter INT
AS
    SELECT *
    FROM   TableA
           LEFT OUTER LOOP JOIN TableB L
             ON @parameter IS NOT NULL
                AND TableA.ID = L.A_ID
           LEFT OUTER MERGE JOIN TableB M
             ON @parameter IS NOT NULL
                AND TableA.ID = M.A_ID
           LEFT OUTER HASH JOIN TableB H
             ON @parameter IS NOT NULL
                AND TableA.ID = H.A_ID;

    O plano para isso após a execução EXEC P1 1é o seguinte.

    insira a descrição da imagem aqui

    • Todos os tipos de junção são capazes de colocar um filtro com um predicado de inicialização acima do operador folha acessando a tabela B. Ou seja, em tempo de execução só é verificado se necessário.
    • As linhas reais e estimadas estão no local para este exemplo.

    No entanto, as linhas estimadas dependem de qual valor de parâmetro é passado quando o plano é compilado. Se NULLtiver sido passado, o número estimado de linhas no operador final é 1.37074. Neste plano simples, o fato de que 218 linhas podem ser emitidas para uma subárvore com estimativa de 1,37 linhas provavelmente não fará muita diferença, mas poderia fazer se isso fosse parte de uma consulta maior. E mesmo neste exemplo simples, isso pode significar que as concessões de memória para a junção de hash final estão incorretas.

    Logicamente, uma junção externa não pode reduzir o número de linhas, mas por algum motivo o 3 inicial é reduzido para 1,37074 depois de passar pelas outras duas junções externas aqui.

    Se forem necessárias estimativas de cardinalidade um tanto precisas, WITH RECOMPILEisso resolverá esse problema - as estimativas de cardinalidade são 1.37074ou 218dependem da nulidade do parâmetro. Mas OPTION (RECOMPILE)seria preferível. Além de ser direcionado para a declaração específica, também permite simplificações adicionais.

    Com OPTION (RECOMPILE)em vigor, o plano de execução ao chamar com NULLé como abaixo.

    insira a descrição da imagem aqui

    As linhas reais e estimadas estão no local e todos os operadores redundantes foram removidos do plano (para que não gaste tempo criando entrada de compilação para a junção de hash desnecessária neste caso).

    Planos acima gerados na compilação 14.0.1000.169

    • 3

relate perguntas