sql-server – 外部应用vs左连接性能

我正在使用SQL SERVER 2008 R2

我刚刚在SQL中遇到了APPLY,并且喜欢它解决了很多情况下的查询问题,

我正在使用的许多表格左边加入以获得结果,我能够获得1个外部申请.

我在本地数据库表中有少量数据,在部署之后,代码应该在至少20倍的数据上运行.

我担心外部应用可能需要比大量数据的2个左连接条件更长的时间,

任何人都可以告诉具体应用的工作原理以及它如何影响非常大的数据的性能,
如果可能的话,与每个表的大小成比例关系,例如与n1 ^ 1或n1 ^ 2 …成比例,其中n1是表1中的行数.

这是带有2个左连接的查询

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,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

这是带有外部申请的查询

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

解决方法

Can anyone tell how exactly apply works and how will it effect the performance in very large data

APPLY是一个相关联接(在某些产品和SQL标准的较新版本中称为LATERAL JOIN).与任何逻辑结构一样,它对性能没有直接影响.原则上,我们应该能够使用任何逻辑上等效的语法编写查询,并且优化器会将输入转换为完全相同的物理执行计划.

当然,这需要优化器知道每个可能的转换,并有时间考虑每个转换.这个过程可能需要比现在的宇宙年龄更长的时间,因此大多数商业产品都不采用这种方法.因此,查询语法可能并且通常会对最终性能产生影响,但很难对哪个更好以及为什么做出一般性陈述.

OUTER APPLY(SELECT TOP …)的特定形式最有可能导致SQL Server当前版本中的相关嵌套循环连接,因为优化器不包含将此模式转换为等效JOIN的逻辑.如果外部输入很大,并且内部输入未编入索引,或者所需页面尚未在内存中,则相关嵌套循环连接可能无法正常执行.此外,优化程序的成本模型的特定元素意味着相关的嵌套循环连接比语义相同的JOIN更不可能生成并行执行计划.

I was able to make same query with single left join and row_number()

在一般情况下,这可能会或可能不会更好.您需要使用代表性数据对两种备选方案进行性能测试. LEFT JOIN和ROW_NUMBER肯定有可能更高效,但它取决于所选择的精确查询计划形状.影响此方法效率的主要因素是索引的可用性,以覆盖所需的列,并提供PARTITION BY和ORDER BY子句所需的顺序.第二个因素是表的大小.如果查询触及相关表的相对较小的部分,则有效且索引良好的APPLY可以优于具有最佳索引的ROW_NUMBER.需要进行测试.