-1

为什么第一次运行缓慢?我能做些什么来避免这种情况?

create PROCEDURE [dbo].[GetMicrosoftXmlFeedData]   
    @PageTemplateIds varchar(500),  
    @PageTemplateLocationIds varchar(500),  
    @ContentTypeIds varchar(500),  
    @PageSourceIds varchar(500),  
    @NumberOfDays int  = 1  
    AS  
      BEGIN  
          select    
           P.pageid  
      , P.maskurl as ArticleURL  
      , C.ContentID  
      , cast(C.ContentXML as xml).value('Content[1]/Headline[1]','varchar(200)') as Headline   
      , cast(C.ContentXML as xml).value('Content[1]/Byline [1]','varchar(200)') as AuthorName  
      , cast(C.ContentXML as xml).value('Content[1]/Deck[1]','varchar(200)') as Description  
      , cast(C.ContentXML as xml).value('Content[1]/BodyContent[1]','varchar(max)') as ArticleDetails  
      , C.DateCreated as POSTING_DATETIME
from cmspage(nolock) P 
   join cmspagecontent(nolock)  PC on P.pageid = PC.pageid  
   join cmsContent(nolock) C on PC.contentid = C.contentid  
   join cmsContentType(nolock) CT on C.ContentTypeId = CT.ContentTypeId  
      where  C.DateCreated > getdate() - @NumberOfDays --100  
        AND    P.pagetemplateid in  (  
          select value from dbo.fnParseDelimString(@PageTemplateIds, ',')  
         --15252, --Article  
        --16543 -- Article - Infogram  
         )   
        and    PC.pagetemplatelocationid in  (  
          select value from dbo.fnParseDelimString(@PageTemplateLocationIds, ',')  
          --17163,  
           --15250  
           )   
        and    CT.contenttypeid in (select value from     dbo.fnParseDelimString(@ContentTypeIds, ','))--(6)   
        and    P.isactive = 1  
        and    P.HasBeenPublished = 1  
        and    P.IsRedirect = 0   
        --and  
            --C.DateCreated > getdate() - @NumberOfDays --100  
        and  
            P.pagesourceid in (select value from dbo.fnParseDelimString(@PageSourceIds,      ','))--(16,1896)  

      END   
4

1 回答 1

2

当 SQL 第一次运行查询时,它会编译查询并为后续执行创建查询计划。因此,最初的延迟是 SQL 试图根据模式、索引和统计信息找出使用什么逻辑来最有效地查找数据。

您在那里的查询并不是特别疯狂,但是通过所有这些子选择,我可以看到为什么服务器可能需要一些时间来确定正确的计划。考虑将一个巨大的查询分解为几个分阶段的查询,并构建简单的表来连接最终结果。

更多关于查询计划 - http://en.wikipedia.org/wiki/Query_plan

这也可能有问题,在将其添加到 where 子句之前计算此值。否则,SQL 可能会为每个行比较计算 GETDATE(),从而导致额外的缓慢。类似地,函数调用可能会尝试解析每一行的值(然后它可能只是导致编译花费这么长时间的原因)。

getdate() - @NumberOfDays
fnParseDelimString
于 2013-09-11T18:22:18.160 回答