Es wird immer empfohlen, beim Schreiben von Abfragen oder SQL Server-Datenbankcode (Prozeduren und Ansichten) den Ausführungsplan zu beachten. Dafür gibt es mehrere Gründe. Erstens – der Optimierer wählt möglicherweise einen Plan, den Sie nicht erwarten. Beispielsweise das Index-Scannen einer großen Tabelle vor dem Abgleich mit einer kleineren Tabelle. Zweitens – es sollte berücksichtigt werden, wie sich diese Abfrage in den kommenden Monaten oder Jahren verhalten wird, wenn die Abfragen in einem neuen System mit kleinen Tabellen ausgeführt werden, die wachsen werden. Und schließlich, aber am wichtigsten, wie schnell ist diese Abfrage und wie viel Ressourcen verbraucht sie. Der letzte Punkt scheint vielleicht nicht so wichtig zu sein, Sie denken vielleicht, dass es gut genug ist, solange es weniger als 3 Sekunden dauert, aber wenn es in <1 Sekunde laufen könnte, wäre das nicht besser? Wenn Ihre Datenbanken in der Cloud gehostet werden, können Sie durch die Reduzierung von Ressourcen auch Geld sparen.
Viele Fälle für die SQL-Optimierung resultieren normalerweise aus einem Problem, das vom Endbenutzer oder Ihrer Überwachungssoftware erkannt wird. „Warum dauert die Erstellung dieses Berichts 30 Minuten?“, „Was verursacht diesen Anstieg der E/A-Wartezeit“ oder „Warum dauert die Ausführung dieser Jobs doppelt so lange wie im letzten Jahr?“
In all diesen Szenarien kommt es immer noch auf ein gewisses Wissen über Ausführungspläne und den besten Weg zur Korrektur der SQL an, um die Situation zu verbessern, und dies kann sehr zeitaufwändig und nicht immer erfolgreich sein.
Nehmen wir ein Beispiel. Sie schreiben also eine neue Abfrage, führen sie aus und denken dann, oh je, das dauert zu lange.
17 Sekunden für 730 Zeilen, was soll ich tun?
Sehen wir uns zunächst den Ausführungsplan an:
Dies ist nicht immer einfach, wenn Sie hinein- und herauszoomen müssen, um es zu verstehen. Der erste Ratschlag ist also, sich einen guten Plan-Viewer wie diesen mit dem Spotlight Tuning Pack zu besorgen.
Der Plan Viewer hebt die wichtigsten Informationen hervor, die wir benötigen, und zeigt, wo sich die Hauptoperationen befinden, sowie alle Warnungen.
Hier ist ein Beispiel:
Es gibt also ein Problem mit diesem Code, aber was können wir dagegen tun?
Naja, eigentlich ziemlich viel. Wir könnten Abfragehinweise verwenden, einige Indizes hinzufügen (vergessen Sie nicht, dass sich dies auf andere Abfragen und DML auswirken kann), Codebits hinzufügen, die die Ergebnismenge nicht ändern, aber den Optimierer beeinflussen, einen anderen Plan zu generieren, und kleine Tricks dazu Stoppen Sie den Optimierer, der einen bestimmten Index berücksichtigt, den er verwendet, und generieren Sie möglicherweise einen neuen Plan. Aber das ist alles Trial-and-Error und sehr zeitaufwändig, um es manuell zu tun.
Indem wir die Anwendung Spotlight Extensions zu SSMS hinzufügen und das Spotlight Tuning Pack abonnieren, können wir die Optimierungsfunktion im Tuning Pack die ganze harte Arbeit für uns erledigen lassen.
Im ersten Screenshot ist Ihnen vielleicht aufgefallen, dass bei aktivierter Funktion automatisch erkannt wird, dass eine Optimierung möglich ist:
Klicken Sie auf Analyse anzeigen
Sie können dann auf die Schaltfläche „Optimieren“ klicken, und die Optimierungs-Engine analysiert den Code und beginnt mit der Anwendung von Umschreibungsregeln, die die Syntax der SQL ändern und Alternativen angeben, die denselben Ergebnissatz liefern, und sie dann testen, damit wir sehen können, ob es eine alternative Ausführung gibt Pläne sind schneller und warum. Die Regeln werden in Kombinationen angewendet, sodass die möglichen Alternativen über 100 liegen können. Das Tool zeigt Ihnen jedoch nur Alternativen an, die schneller als das Original sind.
Dieser Prozess läuft im Hintergrund und spart Ihnen viel Zeit, wenn Sie versuchen, dies manuell zu tun.
Und wenn die Ergebnisse angezeigt werden, können Sie die Alternativen vergleichen, die Codeunterschiede sehen, die Pläne vergleichen und die Statistiken überprüfen.
Zurück zu SSMS mit meiner neuen Version der Abfrage und Testen.
Erfolg.
Wenn dies in einer Entwicklungsumgebung geschieht, sollten Sie erwägen, den Puffercache mit DBCC DROPCLEANBUFFERS zu leeren, um Ihre Abfragen mit einem kalten Puffercache zu testen, ohne den Server herunterzufahren und neu zu starten.
Erwägen Sie auch, der Abfrage SET STATISTICS IO ON hinzuzufügen, um weitere Informationen darüber zu erhalten, warum die Abfragesyntax einen Unterschied gemacht hat:
Original:
Umschreiben:
Und dies kann auch im Tuning Pack mit der Statistik-Vergleichsfunktion erreicht werden:
Also, mit dem erfolgreichen Wechsel und zufriedenen Endnutzern, auf zur nächsten Anfrage. Indem wir die Leistung einzelner Abfragen kontinuierlich verbessern, verbessern wir die Leistung der Instanz.
