Fragen zur Interpretation von SQL Ausführungsplänen

Zu meinem Webcast "SQL Server 2005 - Interpretation von Ausführungsplänen", den ich auf Bitte von InsideSQL gehalten habe hat mit diese Community eine Liste von Fragen geschickt. Die Antworten möchte ich der Community nicht vorenthalten

Woran erkenne ich einen „optimalen“ Ausführungsplan?

Dafür gibt es keine Regeln. In Summe am Fehlen nicht effizienter Konstrukte.

An welchen Operatoren erkenne ich einen ineffizienten Ausführungsplan?

Wie in meiner Präsentation angegeben:

Allgemein:

Große Zeilenzahlen

Große geschätzte Kosten

Joins:

Nested Loops mit einer hohen Zahl Iterationen (also oberer Zweig mit vielen Zeilen) und/oder geringer Selektivität im unteren Zweig (also Scan über eine größere Tabelle statt Seek)

Hash Joins in häufig verwendeten Abfragen (können oft durch Index auf das Joinkriterium vermieden werden)

Scans:

Table und Clustered Index Scans großer Tabellen/Indizes, wenn für das Ergebnis gar nicht die ganze Tabelle benötigt wird, ebenso Index Scans bei großen Indizes

Andere Operatoren

Große Sorts

Manchmal auch große Repartition Streams

Warum werden Ausführungspläne von „rechts nach links“ und „oben nach unten“ dargestellt?

Warum nicht? Man kann so leicht vom Ergebnis ausgehend den Zweig mit den höchsten Kosten verfolgen.

Was ist der Unterschied zwischen einem „Table Spool“ und einem „Eager Spool“ Operator?

Eager Spool ist ein logischer Operator, Table Spool ein Physischer. Zum Unterschied siehe https://msdn2.microsoft.com/de-de/library/ms191158.aspx

Bookmark Loopups gibt es dem Wort nach in SQL Server 2005 nicht mehr. Nun spricht man von Clustered Index Seeks oder RID (Key) Lookups. Ist dies eher eine Frage der Terminologie oder hat sich der dahinterliegende Mechanismus verändert?

Die Implementation ist anders, zumal sie nicht mehr den Fall von Clustered Indizes abdecken muss (da wird immer ein Clustered Index Scan verwendet, RID Lookups gibt es meines Wissens nur für Heaps). Details habe ich dazu aber auch nicht

Kann ich lange dauernde Abfragen am Ausführungsplan erkennen?

Ja, in den Gesamtkosten. Die Reports des Database Tuning Advisor sind aber sicher aussagekräftiger.

Wenn ich einen suboptimalen Ausführungsplan erkannt habe, wie gehe ich dann weiter vor, um das Problem zu beheben?

Zuerst mal: Überlegen, warum der Ausführungsplan suboptimal ist. Es kann 2 grundsätzliche Gründe geben: Fehlende (oder ggf. überschüssige) Indizes oder ineffiziente Abfragen. In ersterem Fall ist der Database Tuning Advisor oft das Mittel der Wahl. Im zweiteren Fall überlegt man, ob man nicht auch mit effizienteren Abfragekonstrukten auskommen kann, z.B. durch Vermeidung von Ungleich-Bedingungen LIKE (insbesondere mit % am Anfang) und unnötigen Sorts.

Wie speichere ich einen Ausführungsplan im XML Format?

Einfach speichern. Die .sqlplan-Datei ist der XML-Ausführungsplan

Was genau ist USE PLAN und wie und wann verwende ich dies?

Mit USE PLAN kann man einen (gespeicherten) Abfrageplan für die Ausführung einer Abfrage erzwingen. Das kann sinnvoll sein, wenn man Abfragen, die mit verschiedenen Parametern verschiedene Ausführungspläne ergeben auf bestimmte Pläne optimiert werden sollen (geht auch mit anderen Mitteln) oder wenn sich der Query Optimizer irrt. Siehe Dokumentation https://msdn2.microsoft.com/de-de/library/ms186343.aspx

Ich verstehe nicht, was ein „Right Anti Semi Join“ ist.

Ich zitiere die Dokumentation:

„Der logische Operator Right Anti Semi Join gibt alle Zeilen aus der zweiten (unteren) Eingabe aus, für die keine übereinstimmende Zeile in der ersten (oberen) Eingabe vorhanden ist.“

Also z.B. bei manchen NOT IN Abfragen

Zum Beispiel erhält man in AdventureWorksDW einen Right Anti Semi Join mit der Abfrage

select distinct ProductKey from FactInternetSales where ProductKey not in (select ProductKey from FactResellerSales)

Also – gib mit alle Product Keys, die Im Internet, aber nicht über Reseller verkauft wurden.

Wo ist der Unterschied zwischen einem „Estimated“ und den „Actual“ Ausführungsplan?

Bei „Estimated“ wird die Abfrage analysiert, aber nicht ausgeführt. Daher können auch keine tatsächlichen Kosten enthalten sein. Bei Actual wird die Abfrage ausgeführt (und ggf. sogar vorher Statistiken aktualisiert und ähnliche Dinge). Daher enthält der Ausführungsplan auch tatsächlich angefallene Kosten.

Wie kann ich mir den „Actual“ Ausführungsplan anzeigen lassen?

Management Studio: Query->Include Actual Execution Plan und dann die Abfrage ausführen, oder im SQL-Text vor Ausführung der Abfrage SET STATISTICS XML ON (bzw. SET STATISTICS PROFILE ON für den Text-Ausführungsplan)

Gruß,
Steffen