utilizarea actualizării cauzelor variabile pentru a rula foarte lent

Am următoarea întrebare.

  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

E ca un campion. Aproximativ 2 secunde. Apoi atunci când încercați și face dinamic prin următoarele.

      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

Dintr-o dată, este foarte lent.

orice idei bune?

EDITAȚI | ×: Probalby ar fi trebuit să menționeze acest lucru, dar acesta este conținut într-un proc stocat.

A adăugat elementul @StartWeekKey ca parametru pentru proc și revine la rulare în câteva secunde.

0
După cum spune Pst, trebuie să te uiți la planurile de interogare.
adăugat autor Namphibian, sursa

2 răspunsuri

Acest lucru nu este nemaiauzit când diferiții parametri au distribuții diferite foarte , deci planuri diferite bune. Ce se poate întâmpla este ca interogarea să fie executată pentru o anumită valoare, iar apoi acest plan este stocat în cache și reutilizat necorespunzător pentru o valoare diferită.

Dacă este cazul (doar o presupunere - nu pot rula interogarea dvs. pentru a verifica!) Apoi încercați să adăugați:

OPTION (OPTIMIZE FOR (@StartWeekKey UNKNOWN))

la sfârșitul interogării.


Un alt gând: este WeekKey de fapt un int ? este acest tip de problemă de conversie de tip masă?


Nu am cum să le verific; dacă sunt la mila de pe pistă, dați-mi voie să știu, așa că pot elimina un răspuns nefolositor.

0
adăugat

Această întrebare pare să fi fost adresată de mai multe ori înainte, iar răspunsul general este că are legătură cu statisticile.

Încerca:

UPDATE STATISTICS table_or_indexed_view_name

pentru a vă actualiza statisticile și pentru a vedea dacă aceasta face diferența.

0
adăugat
Magie. Multumesc pentru ajutor
adăugat autor Dayton Brown, sursa