0

Ich schreibe eine gespeicherte Prozedur, die Daten für einen Verkaufsbericht erhält. Abfragen sind wie folgt aus:SQL-Ausführungspläne - Der geschätzte Plan scheint genauer zu sein als der tatsächliche Plan

INSERT INTO @FirstQuery 
SELECT t1.*, t2.* 
    FROM t1 
     LEFT JOIN t2 ON t1.idT1 = t2.idT1 
     LEFT JOIN t3 ON t3.idT2 = t2.idT2 
WHERE t1.nonIndexedField = @parameter1 
    AND (t2.idT2 IS NULL 
      OR 
      (@parameter2 = 'XXX' AND t1.indexedField1 = @parameter3) 
      OR 
      (@parameter2 = 'YYY' AND t3.indexedField1 = @parameter3) 
     ) 

Mit diesen Ergebnissen habe ich dann eine zweite Tabelle Variable füllen:

INSERT INTO @SecondQuery 
SELECT u1.*, u2.* 
    FROM u1 
     INNER JOIN u2 ON u2.idU1 = u1.idU1 
WHERE u1.NONindexedField in (SELECT someField FROM @FirstQuery) 

Wie es am QA-Umgebung ziemlich langsam zu sein, ich die Ausführungspläne beobachtet. Zuerst habe ich mir den Plan angeschaut. Es hat gesehen, dass SecondQuery sehr lange dauerte, und ich erkannte, dass u1.NONindexedField keinen Index hatte und schätzungsweise 97% der Gesamtkosten einnahm. Aber dann habe ich einen Blick auf den aktuellen Plan geworfen, der besagt, dass FirstQuery 100% der Gesamtkosten übernommen hat. Ich überprüfte die geschätzten Zeilen, die auf dem geschätzten Plan berechnet wurden, und es gab viele Orte, an denen es nur sehr wenige Reihen schätzte, wo der tatsächliche Plan ungefähr hundert Hundert (100K) zeigte. Ich dachte, es war, weil das Feld, das einen Index fehlte, in einer Tabelle mit nicht so vielen Reihen (17K) war, aber ich schuf den Index irgendwie. Zu meiner Überraschung wurde die Abfragezeit von 500 auf 15 Sekunden reduziert. Also, meine Frage ist ... warum so ein Unterschied in Ausführungspläne, und wie kommt der eigentliche Plan weg war? Ich weiß, dass der geschätzte Plan nicht wirklich "eine Schätzung des Plans" bedeutet, sondern "einen Plan mit geschätzten Zeilenzahlen", aber das erklärt nicht den Unterschied und erklärt gewiss nicht, warum der Plan mir das alles gesagt hat Die Kosten betrafen eine Abfrage, die nicht optimiert werden musste ...

BTW, ich habe die relativen Zeiten verglichen, und die zweite Abfrage dauert in der Tat rund 97% der gesamten Ausführungszeit.

Danke fürs Lesen!

Antwort

0

Wenn der eigentliche Plan weit weg war, könnte dies durch veraltete Statistiken verursacht werden.

Haben Sie versucht, Statistiken zu den Tabellen in der Abfrage zu aktualisieren.

Wenn die Statistiken veraltet sind, kann dies dazu führen, dass die Ausführungspläne deaktiviert sind. Mit nicht aktualisierten Statistiken sind Ihre Abfragen möglicherweise sehr ineffizient.

die Syntax für die Statistik zu aktualisieren ist:

update statistics tablename; 

Versuchen Sie, die Statistiken zu aktualisieren und sehen Sie, wenn Sie genauere Ausführungspläne bekommen.

+0

Danke für die Antwort! Ich habe aktualisierte Statistiken für alle beteiligten Tabellen erstellt und es hat nicht geholfen. Der eigentliche Ausführungsplan hat sich nicht geändert. –

Verwandte Themen