Desempenho de aplicação externa versus junção esquerda

Estou usando o SQL SERVER 2008 R2

Acabei de encontrar o APPLY no SQL e adorei como ele resolve problemas de consulta em muitos casos,

Muitas das tabelas que eu estava usando 2 join esquerdo para obter o resultado, consegui entrar em uma aplicação externa.

Tenho uma pequena quantidade de dados em minhas tabelas de banco de dados locais e, após a implantação, o código deve ser executado em dados com pelo menos 20 vezes o tamanho máximo.

Estou preocupado que a aplicação externa possa demorar mais do que as duas condições de junção restantes para grande quantidade de dados,

Alguém pode dizer exatamente como a aplicação funciona e como isso afetará o desempenho em dados muito grandes? Se possível, algumas relações proporcionais com o tamanho de cada tabela, como proporcional a n1 ^ 1 ou n1 ^ 2 ... onde n1 é o número de linhas na tabela 1

Aqui está a consulta com 2 associações à esquerda

select EC.*,DPD.* from Table1 eC left join
  (
   select member_id,parent_gid,child_gid,LOB,group_gid,MAX(table2_sid) mdsid from Table2
   group by member_id,parent_gid,child_gid,LOB,group_gid

  ) DPD2 on DPD2.parent_gid = Ec.parent_gid
        AND DPD2.child_gid = EC.child_gid
        AND DPD2.member_id = EC.member_id
        AND DPD2.LOB = EC.default_lob
        AND DPD2.group_gid = EC.group_gid
  left join
  Table2 dpd on dpd.parent_gid = dpd2.parent_gid 
            and dpd.child_gid = dpd2.child_gid
            and dpd.member_id = dpd2.member_id 
            and dpd.group_gid = dpd2.group_gid 
            and dpd.LOB = dpd2.LOB
            and dpd.table2_sid = dpd2.mdsid

Aqui está a consulta com aplicação externa

select * from Table1 ec   
OUTER APPLY (
      select top 1 grace_begin_date,retroactive_begin_date,Isretroactive
                    from Table2 DPD 
                    where DPD.parent_gid = Ec.parent_gid
                    AND DPD.child_gid = EC.child_gid
                    AND DPD.member_id = EC.member_id
                    AND DPD.LOB = EC.default_lob
                    AND DPD.group_gid = EC.group_gid
                    order by DPD.table2_sid desc
     ) DPD 

Alguém pode dizer como exatamente a aplicação funciona e como isso afetará o desempenho em dados muito grandes

APPLYé uma junção correlacionada (chamada LATERAL JOINem alguns produtos e versões mais recentes do SQL Standard). Como qualquer construção lógica, não tem impacto direto no desempenho. Em princípio, poderíamos escrever uma consulta usando qualquer sintaxe logicamente equivalente, e o otimizador transformaria nossa entrada exatamente no mesmo plano de execução física.

Obviamente, isso exigiria que o otimizador conhecesse todas as transformações possíveis e tivesse tempo para considerar cada uma delas. Esse processo pode levar mais tempo do que a idade atual do universo; portanto, a maioria dos produtos comerciais não adota essa abordagem. Portanto, a sintaxe da consulta pode, e geralmente afeta, o desempenho final, embora seja difícil fazer declarações gerais sobre qual é o melhor e por quê.

A forma específica de OUTER APPLY ( SELECT TOP ... )provavelmente resultará em uma junção aninhada correlacionada nas versões atuais do SQL Server, porque o otimizador não contém lógica para transformar esse padrão em um equivalente JOIN. A junção de loops aninhados correlacionados pode não ter um bom desempenho se a entrada externa for grande e a entrada interna não for indexada ou as páginas necessárias ainda não estiverem na memória. Além disso, elementos específicos do modelo de custo do otimizador significam que uma junção de loops aninhados correlacionados é menos provável que uma semântica idêntica JOINpara produzir um plano de execução paralelo.

Consegui fazer a mesma consulta com a junção esquerda única e o número da linha ()

Isso pode ou não ser melhor no caso geral. Você precisará testar as duas alternativas com dados representativos. O LEFT JOINe ROW_NUMBERcertamente tem potencial para ser mais eficiente, mas depende da forma precisa do plano de consulta escolhido. Os principais fatores que afetam a eficiência dessa abordagem são a disponibilidade de um índice para cobrir as colunas necessárias e fornecer a ordem necessária pelas cláusulas PARTITION BYe ORDER BY. Um segundo fator é o tamanho da tabela. Um eficiente e bem indexado APPLYpode ter um desempenho ROW_NUMBERcom uma indexação ideal se a consulta tocar uma parte relativamente pequena da tabela em questão. Teste é necessário.

A primeira consulta pode ser executada paralelamente por apenas uma solicitação ao servidor sql. Ele buscou o registro all e fornece a saída com base nos critérios de filtro.

Mas no caso do segundo, ele é executado linha por linha e, para cada linha, a Tabela2 será varrida e anexada ao resultado.

se a sua consulta externa tiver menos registros, a segunda será melhor (EXTERIOR APLICAR). Mas se a primeira consulta pode obter mais dados, você deve usar a primeira.