Es ist einfach, mit den Zahnrädern der SQL-Abfrageoptimierung zu basteln. Sie öffnen SQL Server Management Studio (SSMS), überwachen die Wartezeit, überprüfen den Ausführungsplan, sammeln Objektinformationen und beginnen mit der Optimierung von SQL, bis Sie eine fein abgestimmte Maschine ausführen.
Wenn Sie gut genug darin sind, erzielen Sie einen schnellen Sieg und kehren zu Ihrem regelmäßig geplanten Chaos zurück. Aber wenn du das Falsche einstellst oder das Richtige in die falsche Richtung einstellst, dann ist dein Mittwoch vorbei.
SQL-Abfrageoptimierung? Warum denkst du, dass du es brauchst?
Meistens handelt es sich um einen Anstieg von Trouble-Tickets oder Benutzerbeschwerden. „Warum ist das System so langsam?“ Ihre Benutzer beschweren sich. „Wir brauchen diese Woche ewig, um unsere üblichen Berichte zu erstellen.“
Das ist natürlich eine ziemlich vage Beschreibung. Es wäre schön, wenn sie Ihnen sagen könnten:„Die Dinge sind langsam, weil Sie eine implizite Konvertierung in Zeile 62 von CurrentOrderQuery5.sql haben. Die Spalte ist varchar und Sie übergeben eine Ganzzahl.“ Aber es ist unwahrscheinlich, dass Ihre Benutzer diese Detailebene sehen können.
Zumindest Trouble-Tickets und Telefonanrufe sorgen für eine aktive Metrik:leicht zu erkennen, leicht zu messen. Wenn sie anfangen zu rollen, können Sie ziemlich sicher sein, dass es Zeit für das SQL-Tuning ist.
Aber es gibt andere, passive Metriken, die die Notwendigkeit weniger deutlich machen. Dinge wie Umsatzeinbrüche, die auf eine Reihe von Faktoren zurückzuführen sein können. Liegt es daran, dass quälend langsame Abfragen in Ihrem Online-Shop Ihre Kunden dazu bringen, ihren Einkaufswagen abzubrechen? Liegt es daran, dass die Wirtschaft in schlechter Verfassung ist?
Oder es könnte Dinge wie eine träge SQL Server-Leistung sein. Liegt es daran, dass eine schlecht geschriebene Abfrage logische Lesevorgänge durch die Decke schickt? Liegt es daran, dass der Server nicht genügend physische Ressourcen wie Arbeitsspeicher und Speicherplatz hat?
In beiden Szenarien kann die SQL-Abfrageoptimierung bei der ersten Option hilfreich sein, aber nicht bei der zweiten.
Warum die richtige Lösung auf das falsche Problem anwenden?
Bevor Sie den Pfad der Optimierung einschlagen, vergewissern Sie sich, dass die Optimierung die richtige Lösung für das richtige Problem ist.
Das Optimieren von SQL ist ein technischer Prozess, aber jeder technische Schritt hat seine Wurzeln in einem gesunden Geschäftssinn. Sie könnten Tage damit verbringen, die Ausführungszeit um einige Millisekunden zu verkürzen oder die Anzahl der logischen Lesevorgänge um fünf Prozent zu reduzieren, aber ist die Reduzierung Ihre Zeit wert? Es stimmt, dass es wichtig ist, die Anforderungen der Benutzer zu erfüllen, aber jede Anstrengung führt irgendwann zu einem sinkenden Ertrag.
Betrachten Sie diese Leistungsprobleme bei SQL-Abfragen und den sie umgebenden Geschäftskontext:
- Akzeptable Leistung — Die Ausführung einer Abfrage dauert 10 Minuten, und der Benutzer möchte, dass sie in einer Minute ausgeführt wird. das scheint eine vernünftige Ungleichheit und ein erreichbares Optimierungsziel zu sein. Wenn die Abfrage jedoch über Nacht dauert und der Benutzer denkt, dass sie in einer Minute ausgeführt werden sollte, kann es sich um mehr als ein Optimierungsproblem handeln. Zum einen müssen Sie den Benutzer möglicherweise darüber aufklären, wie viel Arbeit die Abfrage tatsächlich leistet. Zum anderen kann es ein Problem mit der Art und Weise sein, wie die Datenbank entworfen oder die Client-Anwendung geschrieben wurde.
- Dienstprogramm — Angenommen, Sie sind für die Verwaltung der Finanzdatenbank in einem Produktionsunternehmen verantwortlich. Am Ende eines jeden Monats beschweren sich Benutzer über eine schlechte Leistung. Sie führen das Problem auf eine Reihe von Monatsendberichten zurück, die von der Buchhaltung erstellt werden und die jeweils Stunden dauern und direkt in einem Aktenschrank landen, ohne von irgendjemandem untersucht zu werden. Anstatt zu tunen, erklären Sie den Geschäftsführern das Problem und holen die Erlaubnis ein, die Berichte zu löschen.
- Zeitverschiebung – Oder nehmen Sie an, dieselben Berichte sind wichtig für die Unternehmensführung, aber nicht dringend für das Unternehmen. Wenn sie einmal pro Woche oder pro Monat ausgeführt werden, können sie für Nebenzeiten geplant werden, indem der Datensatz vorab zwischengespeichert und die Ergebnisse an eine Datei gesendet werden. Dadurch wird der Engpass für die anderen Geschäftsbenutzer beseitigt und der Buchhaltungsbenutzer davon befreit, auf die Berichte warten zu müssen.
Wenn Sie den geschäftlichen Kontext in Ihre Optimierungsentscheidung einbeziehen, können Sie Prioritäten setzen und sich Zeit verschaffen.
Wenn Sie SQL-Abfragen optimieren, versuchen Sie es mit SQL-Diagrammen
SSMS und die in SQL Server integrierten Tools bieten fast alles, was Sie für eine effektive SQL-Abfrageoptimierung benötigen. Kombinieren Sie die Tools mit einem methodischen Ansatz um die folgenden Schritte herum, wie im E-Book „Der grundlegende Leitfaden zur SQL-Abfrageoptimierung“ beschrieben:
- Wartezeit überwachen
- Überprüfen Sie den Ausführungsplan
- Sammeln Sie Objektinformationen
- Fahrtabelle finden
- Leistungshemmnisse identifizieren
In Schritt 4 besteht Ihr Ziel darin, die Abfrage mit der Tabelle zu steuern, die die wenigsten Daten zurückgibt. Wenn Sie Verknüpfungen und Prädikate studieren und eher früher als später in der Abfrage filtern, reduzieren Sie die Anzahl der logischen Lesevorgänge. Das ist ein großer Schritt in der SQL-Abfrageoptimierung.
SQL-Diagramme sind eine grafische Technik, um die Datenmenge in den Tabellen abzubilden und herauszufinden, welcher Filter die wenigsten Datensätze zurückgibt. Zunächst legen Sie fest, welche Tabellen die Detailinformationen enthalten und welche Tabellen die Master- oder Nachschlagetabellen sind. Betrachten Sie das einfache Beispiel dieser Abfrage einer Universitätsdatenbank:
Die Detailtabelle ist die Registrierung. Es hat zwei Nachschlagetabellen, student und class. Um diese Tabellen grafisch darzustellen, zeichnen Sie einen umgekehrten Baum, der die Detailtabelle (oben) mit Pfeilen (oder Links) mit den Nachschlagetabellen verbindet, wie hier:
Berechnen Sie nun die relative Anzahl von Datensätzen, die für die Join-Kriterien erforderlich sind (d. h. das durchschnittliche Verhältnis von Zeilen, die zwischen der Detailtabelle und den Nachschlagetabellen verknüpft sind). Schreibe die Zahlen an jedes Ende des Pfeils. In diesem Beispiel gibt es für jeden Schüler ungefähr 5 Datensätze in der Registrierungstabelle und für jede Klasse gibt es ungefähr 30 Datensätze in der Registrierung. Das bedeutet, dass es nie notwendig sein sollte, mehr als 150 (5×30) Datensätze ZU VERBINDEN, um ein Ergebnis für einen einzelnen Schüler oder eine einzelne Klasse zu erhalten.
Diese Übung ist hilfreich, wenn Ihre Join-Spalten nicht indiziert sind oder wenn Sie nicht sicher sind, ob sie indiziert sind.
Sehen Sie sich als Nächstes die Filterprädikate an, um herauszufinden, mit welcher Tabelle die Abfrage gesteuert werden soll. Diese Abfrage hatte zwei Filter:einen auf Registrierung storniert =„N“ und den anderen auf signup_date zwischen zwei Daten. Um zu sehen, wie selektiv der Filter ist, führen Sie diese Abfrage bei der Registrierung aus:
select count(1) from registration where cancelled =‘N’
UND r.signup_date ZWISCHEN :beg_date UND :beg_date +1
Es gibt 4.344 Datensätze aus den insgesamt 79.800 registrierten Datensätzen zurück. Das heißt, 5,43 Prozent der Datensätze werden mit diesem Filter gelesen.
Der andere Filter ist auf Klasse:
select count(1) from class where name =‘ENGLISH 101’
Es gibt zwei Datensätze von 1.000 oder 0,2 Prozent zurück, was einen viel selektiveren Filter darstellt. Daher ist die Klasse die treibende Tabelle und diejenige, auf die Sie sich beim SQL-Tuning zuerst konzentrieren sollten.
Die Stimme des Benutzers
Wenn Sie sicher sind, dass Sie SQL-Tuning benötigen, bietet „Der grundlegende Leitfaden zur SQL-Abfrageoptimierung“ weitere Einblicke. Es führt Sie durch fünf Tipps zur Leistungsoptimierung mit Copy-and-Paste-Abfragen und Fallstudien, einschließlich der oben beschriebenen.
Sie werden wahrscheinlich feststellen, dass das wichtigste Tool zur Optimierung von SQL-Abfragen die Stimme des Benutzers ist. Wieso den? Weil diese Stimme Ihnen sagt, wann Sie mit der Optimierung beginnen müssen, und sie sagt Ihnen, wann Sie genug optimiert haben. Es kann sicherstellen, dass Sie anfangen, an den Gängen zu basteln, wenn Sie es brauchen, und aufhören, wenn Sie noch vorne liegen.
