4

我有以下查询。

  UPDATE t
  SET    UnitsSold = sub.UnitsSold,
  FROM   dbo.table1 t
         JOIN (SELECT s.CustomerKey,
                      s.WeekKey,
                      s.ProductKey,
                      Sum(s.UnitsSold)          AS [UnitsSold],
               FROM   dbo.table2 s
               WHERE  WeekKey >= 335
               GROUP  BY s.WeekKey,
                         s.CustomerKey,
                         s.ProductKey) AS sub
           ON sub.WeekKey = t.WeekKey
              AND sub.CustomerKey = t.CustomerKey
              AND sub.ProductKey = t.ProductKey

它像冠军一样奔跑。大约2秒。然后尝试通过以下方式使其动态化。

      DECLARE @StartWeekKey AS INT 
        SET @StartWeekKey = 335

  UPDATE t
  SET    UnitsSold = sub.UnitsSold,
  FROM   dbo.table1 t
         JOIN (SELECT s.CustomerKey,
                      s.WeekKey,
                      s.ProductKey,
                      Sum(s.UnitsSold)          AS [UnitsSold],
               FROM   dbo.table2 s
               WHERE  WeekKey >= @StartWeekKey
               GROUP  BY s.WeekKey,
                         s.CustomerKey,
                         s.ProductKey) AS sub
           ON sub.WeekKey = t.WeekKey
              AND sub.CustomerKey = t.CustomerKey
              AND sub.ProductKey = t.ProductKey

突然间，它超级慢。

有什么好主意吗？

编辑：Probalby 应该提到这一点，但这包含在存储过程中。

将@StartWeekKey 作为参数添加到过程中，它会在几秒钟内恢复运行。

4

2 回答 2

1

这个问题似乎已经被问过好几次了，一般的答案是它与统计有关。

尝试：

UPDATE STATISTICS table_or_indexed_view_name

让您的统计数据保持最新状态，看看是否有所作为。

于 2012-06-04T18:59:22.473 回答
0

当不同的参数有非常不同的分布时，这并不是闻所未闻的，因此有不同的好计划。可能发生的情况是查询针对给定值执行，然后该计划被缓存并不适当地重新用于不同的值。

如果是这种情况（只是猜测 - 我无法运行您的查询来检查！）然后尝试添加：

OPTION (OPTIMIZE FOR (@StartWeekKey UNKNOWN))

到查询结束。

另一个想法：WeekKey实际上是一个int？这是某种质量类型转换问题吗？

我无法检查这些；如果我偏离了轨道，请告诉我，以便我可以删除无用的答案。

于 2012-06-04T19:03:39.493 回答