Einer der besten Aspekte der SQL-Sprache ist, dass die Befehle dank ihrer einfachen Syntax leicht zu erlernen und zu befolgen sind.

Aber hier ist der Haken: Nicht alle Datenbankfunktionen sind effizient. Zwei Abfragen können zwar ähnlich aussehen, unterscheiden sich aber in der Rechenzeit, und das macht den Unterschied aus. Deshalb ist die Feinabstimmung von SQL-Abfragen unerlässlich.

Wenn Sie eine Organisation sind, die eine Live-Produktionsdatenbank für Reporting-Zwecke und zum Extrahieren aktueller Daten verwendet, ist es sogar wichtig, SQL-Abfragen zu optimieren, um die Ressourcen der Produktionsdatenbank nicht unnötig zu belasten.

Wege zur Feinabstimmung Ihrer SQL-Abfragen

Haben Sie eine klare Reihe von Geschäftsanforderungen, bevor Sie beginnen

Eine der besten Möglichkeiten, SQL-Abfragen zu optimieren, besteht darin, die richtigen Dinge von Anfang an zu tun. Stellen Sie also sicher, dass Sie, bevor Sie beginnen, die folgenden Punkte abgehakt haben:

  • Haben Sie die relevanten Stakeholder erkannt?
  • Es ist wichtig, alle relevanten Personen und Teams bei der Entwicklung der Abfrage einzubeziehen. Zusätzlich ist es sogar wichtig, das DBA-Team bei der Abfrage von Produktionsdatenbanken einzubeziehen.

  • Haben Sie Ihre Anforderungen erkannt?
  • Die beste Methode, um sicherzustellen, dass alle Ihre Anforderungen erfüllt werden, ist die Beantwortung von 5 Fragen: Wer? Warum? Was? Wann? Wo?

  • Sind die identifizierten Anforderungen spezifisch und auf den Punkt gebracht?
  • Die Produktionsdatenbank spielt eine entscheidende Rolle. Die Datenbank mit unklaren Anforderungen zu belasten, ist viel zu riskant. Bevor Sie also eine Abfrage starten, stellen Sie sicher, dass alle Anforderungen spezifisch sind und mit den entsprechenden Beteiligten besprochen wurden

    Beherrschen Sie die Kunst, Indizes richtig zu erstellen

    Performance-Tuning in SQL kann durch richtiges Indizieren erfolgen, was zu einem schnelleren Zugriff auf die Datenbank in kritischen Zeiten führt. Dies ist ein Bereich, in dem die meisten Datenbank-Neulinge versagen. Sie versuchen entweder, alles zu indizieren oder nichts zu indizieren, und keiner dieser Ansätze funktioniert zu ihren Gunsten.

    Denn wenn Sie überhaupt keine Indizierung vornehmen, werden Ihre Abfragen langsam laufen und die Datenbank unnötig belasten. Auf der anderen Seite, wenn Sie alles indizieren, werden Ihre Insert-Trigger nicht wie erwartet funktionieren, was Ihre Datenbank ineffizient macht. Der Schlüssel hier ist, die richtige Balance zu finden.

    Vermeiden Sie die Verwendung von SELECT*

    SELECT* (gelesen als select all) wird oft als Abkürzung verwendet, um alle Daten aus einer Tabelle abzufragen. Obwohl diese Methode für kleinere Tabellen gut funktioniert, belastet sie die Datenbankressourcen unnötig, wenn eine Abfrage auf eine Tabelle mit vielen Feldern und Zeilen abgefeuert wird.

    Der beste Weg ist hier, die Felder in der SELECT-Anweisung zu definieren, um die Datenbank anzuweisen, nur die benötigten Daten abzufragen, um die Endziele zu erreichen.

    Lassen Sie uns dies anhand eines Beispiels besser verstehen:

    Hier ist ein ineffizienter Weg, da diese Abfrage alle Daten abruft, die in der Tabelle „Benutzer“ gespeichert sind, unabhängig von Ihren Bedürfnissen.

    SELECT*
    FROM Users

    Dies ist die effizientere Art der Abfrage, da sie nur die benötigten Informationen abruft und verhindert, dass Ihre Datenbank belastet wird.

    SELECT LastName, Address, Contact
    FROM Users

    Temporäre Tabellen sinnvoll verwenden

    Obwohl temporäre Tabellen großartig zu verwenden sind, erhöhen sie die Komplexität einer Abfrage exponentiell. Es wird dringend empfohlen, die Verwendung von temporären Tabellen zu vermeiden, wenn Ihr Code einfach geschrieben werden kann.

    Wenn Sie jedoch mit einer gespeicherten Prozedur umgehen müssen, die nicht mit einer einzigen Abfrage bewältigt werden kann, kann die Verwendung von temporären Tabellen als Vermittler Ihrem Ärger ein Ende bereiten.

    Vermeiden Sie die Verwendung von COUNT()

    Eine der üblichen Methoden, mit denen Entwickler prüfen, ob ein bestimmter Datensatz existiert, ist die Verwendung von COUNT() anstelle von EXISTS(). COUNT() ist ineffizient, weil es die gesamte Tabelle durchsucht und alle Abfragen zählt, die Ihre Bedingung erfüllen. Dagegen ist EXISTS() effizienter, da es die Schleife verlässt, sobald es das gewünschte Ergebnis findet. Dies trägt zu einer besseren Funktionsweise bei und sorgt für einen saubereren Code.

    Vermeiden Sie die Verwendung von Platzhalterzeichen am Anfang des LIKE-Musters

    Um Ihre SQL-Abfragen fein abzustimmen, müssen Sie die Verwendung von LIKE-Mustern auf folgende Weise vermeiden:

    SELECT* FROM Customers WHERE address LIKE ‘%bar%’;

    Hier kann die Datenbank einen passenden Index nicht verwenden, wenn er aufgrund von %-Platzhaltern existiert. Das System führt zunächst einen vollständigen Tabellenscan durch und das geht auf Kosten der Geschwindigkeit. Der bessere Weg, diese Abfrage zu schreiben, ist daher:

    SELECT* FROM Customers WHERE address LIKE ‘bar%’;

    Vermeiden Sie die Verwendung von SELECT DISTINCT

    Obwohl Sie mit SELECT DISTINCT leicht Duplikate aus einer Abfrage eliminieren können, verbraucht diese Funktion eine beträchtliche Menge an Verarbeitungsleistung. Außerdem funktioniert diese Abfrage, indem sie alle Felder in der Abfrage gruppiert, um unterschiedliche Ergebnisse zu präsentieren. Das macht sie wiederum sehr ungenau.

    Die bessere Möglichkeit, doppelte Datensätze in Ihrer Abfrage zu vermeiden, ist das Hinzufügen weiterer Felder. Auf diese Weise ist keine Gruppierung erforderlich, und die abgefragten Datensätze sind genau.

    Hier ein Beispiel für eine ineffiziente Vorgehensweise:

    SELECT DISTINCT FirstName, LastName, State
    FROM Users

    Und hier ist die effiziente Methode, dies zu tun:

    SELECT FirstName, LastName, Contact, Address, State, Zip
    FROM Users

    Bonustipp: Halten Sie einige Abfragen für die Randzeiten bereit

    Um sicherzustellen, dass Ihre Produktionsdatenbank sicher und stabil bleibt, ist es sehr empfehlenswert, bestimmte Abfragen für Randzeiten zu planen, idealerweise dann, wenn die Anzahl der gleichzeitigen Benutzer am geringsten ist. So ist die Mitte der Nacht, 3-5 Uhr morgens ist die beste Zeit, um Abfragen wie diese auszuführen:

    • Schleifenanweisungen
    • Ausführen von SELECT* auf großen Tabellen mit über 1 Million Datensätzen
    • Verschachtelte Unterabfragen
    • Wildcard-Suchen
    • CROSS JOINs
    • SELECT DISTINCT-Anweisungen

    The Wrap Up

    Performance-Tuning in SQL ist wichtig, um Ihre Datenbank gesund zu halten, aber es ist nicht die einfachste Aufgabe, die zu bewältigen ist. Die Leistung Ihrer SQL-Abfragen hängt von einer Reihe von Faktoren ab, wie z. B. Ihrem Datenbankmodell, der Art der Informationen, die Sie abrufen müssen, und so weiter.

    Es ist sehr empfehlenswert, unangenehme Situationen zu vermeiden, indem Sie einen Überblick über alle Abfragen behalten, die bald abgefeuert werden, und die besten Lösungen anbieten. Als DBA könnten Sie die Entwickler auch mit einem datengesteuerten Dashboard ausstatten, damit sie nicht hin und wieder Abfragen abfeuern müssen, um die wichtigen Informationen zu holen. Hier ist ein erstaunlicher Artikel darüber, wie Sie ein SQL-Dashboard erstellen können, das Daten direkt aus der Datenbank zieht.

    Was sind Ihre Ansichten dazu? Wie stimmen Sie Ihre SQL-Abfragen ab? Lassen Sie es uns wissen.

    Schreibe einen Kommentar

    Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.