SQL存儲過程性能很好SQL2008，但在SQL2005很糟糕

Question

我有一個存儲過程，我已經開發了SQL2008服務器上運行< 1秒。在另一臺SQL2005服務器上，同一個數據庫上的同一個服務器需要大約1分鐘的時間。沒有深入瞭解數據庫模式的細節，任何人都可以在此SP中看到任何可能導致此性能差異的顯而易見的內容？這可能是CTE的使用嗎？有其他選擇嗎？

編輯 - 我現在已經注意到，如果我直接在SQL 2005上運行SQL它運行在〜4secs但執行SP仍需要一分鐘？看起來問題可能會在SP執行？

CREATE PROCEDURE Workflow.GetTopTasks 
    -- Add the parameters for the stored procedure here 
    @ownerUserId int, 
    @topN int = 10 
AS 
BEGIN 
    -- SET NOCOUNT ON added to prevent extra result sets from 
    -- interfering with SELECT statements. 
    SET NOCOUNT ON; 

    SET ROWCOUNT @topN; 

    -- Insert statements for procedure here 

WITH cteCalculatedDate (MilestoneDateId, CalculatedMilestoneDate) 
AS 
(
-- Anchor member definition 
    SELECT md.MilestoneDateId, md.SpecifiedDate 
    FROM Workflow.MilestoneDate md 
    WHERE md.RelativeMilestoneDateId IS NULL 
UNION ALL 
-- Recursive member definition 
    SELECT md.MilestoneDateId, CalculatedMilestoneDate + md.RelativeDays 
    FROM Workflow.MilestoneDate md 
      INNER JOIN cteCalculatedDate cte 
       on md.RelativeMilestoneDateId = cte.MilestoneDateId 
) 

-- Statement that executes the CTE 

    select 
     we.* 
    from Workflow.WorkflowElement we 
     left outer join cteCalculatedDate cte 
      on cte.MilestoneDateId = we.DueDateId 
     inner join Workflow.WorkflowInstance wi 
      on wi.WorkflowInstanceId = we.WorkflowInstanceId 
     left outer join Workflow.SchemeWorkflow sw 
      on sw.WorkflowInstanceId = wi.WorkflowInstanceId 
     left outer join Workflow.Scheme s 
      on s.SchemeId = sw.SchemeId 
     inner join Workflow.WorkflowDefinition wd 
      on wd.WorkflowDefinitionId = wi.WorkflowDefinitionId 
    where 
     we.OwnerId = @ownerUserId   -- for given owner 
     and we.CompletedDate is null  -- is not completed 
     and we.ElementTypeId <= 4   -- is Action, Data, Decision or Document (Not End, Start or KeyDate) 
     and cte.CalculatedMilestoneDate is not null -- has a duedate 

    UNION 

    select 
     we.* 
    from Workflow.WorkflowElement we 
     left outer join cteCalculatedDate cte 
      on cte.MilestoneDateId = we.DueDateId 
     inner join Workflow.WorkflowInstance wi 
      on wi.WorkflowInstanceId = we.WorkflowInstanceId 
     left outer join Workflow.SchemeWorkflow sw 
      on sw.WorkflowInstanceId = wi.WorkflowInstanceId 
     left outer join Workflow.Scheme s 
      on s.SchemeId = sw.SchemeId 
     inner join Workflow.WorkflowDefinition wd 
      on wd.WorkflowDefinitionId = wi.WorkflowDefinitionId 
    where 
     we.OwnerId = @ownerUserId   -- for given owner 
     and we.CompletedDate is null  -- is not completed 
     and we.ElementTypeId <= 4   -- is Action, Data, Decision or Document (Not End, Start or KeyDate) 
     and cte.CalculatedMilestoneDate is null -- does NOT have a duedate 

    SET ROWCOUNT 0 

END 

Answer 1

您的工會正在選擇CalculatedMilestoneDate等於NULL 和不等於Null。

這是多餘的，只需從where子句中去除CalculatedMilestoneDate上的條件即可刪除整個UNION。

除此之外，您應該驗證兩個數據庫是否具有相同的索引定義。

-- Statement that executes the CTE 

    select 
     we.* 
    from Workflow.WorkflowElement we 
     left outer join cteCalculatedDate cte 
      on cte.MilestoneDateId = we.DueDateId 
     inner join Workflow.WorkflowInstance wi 
      on wi.WorkflowInstanceId = we.WorkflowInstanceId 
     left outer join Workflow.SchemeWorkflow sw 
      on sw.WorkflowInstanceId = wi.WorkflowInstanceId 
     left outer join Workflow.Scheme s 
      on s.SchemeId = sw.SchemeId 
     inner join Workflow.WorkflowDefinition wd 
      on wd.WorkflowDefinitionId = wi.WorkflowDefinitionId 
    where 
     we.OwnerId = @ownerUserId   -- for given owner 
     and we.CompletedDate is null  -- is not completed 
     and we.ElementTypeId <= 4   -- is Action, Data, Decision or Document (Not End, Start or KeyDate) 

Answer 2

如果模式匹配，那麼你可能在sql server 2005實例中缺少重要的索引。嘗試運行sql server調優顧問並應用其索引建議。

Answer 3

編輯 - 我現在已經注意到，如果我 對SQL直接運行SQL中〜4secs 2005年，它 運行，但執行SP 仍然需要一分鐘？

錯誤的參數嗅探則：2005年

http://elegantcode.com/2008/05/17/sql-parameter-sniffing-and-what-to-do-about-it/

SQL poor stored procedure execution plan performance - parameter sniffing

參數嗅探很糟糕，但在2008年