Lieblings-Performance-Tuning-Tricks [geschlossen]

Was sind die ersten Dinge, die Sie versuchen, wenn Sie eine Abfrage oder eine gespeicherte Prozedur haben, für die eine Leistungsoptimierung erforderlich ist?

Hier ist die praktische Liste der Dinge, die ich immer jemandem gebe, der mich nach der Optimierung fragt.
Wir verwenden hauptsächlich Sybase, aber die meisten Ratschläge gelten allgemein.

SQL Server enthält zum Beispiel eine Vielzahl von Leistungsüberwachungs- / Optimierungsbits. Wenn Sie jedoch nichts dergleichen haben (und vielleicht sogar, wenn Sie dies tun), würde ich Folgendes in Betracht ziehen ...

99% der Probleme, die ich gesehen habe, werden durch das Einfügen zu vieler Tabellen in einen Join verursacht . Die Lösung hierfür besteht darin, die Hälfte des Joins (mit einigen Tabellen) durchzuführen und die Ergebnisse in einer temporären Tabelle zwischenzuspeichern. Führen Sie dann den Rest der Abfrage aus, die in dieser temporären Tabelle verknüpft ist.

Checkliste zur Abfrageoptimierung

• Führen Sie UPDATE STATISTICS für die zugrunde liegenden Tabellen aus
  • Viele Systeme führen dies als geplanten wöchentlichen Job aus
• Löschen von Datensätzen aus zugrunde liegenden Tabellen (möglicherweise archivieren Sie die gelöschten Datensätze)
  • Tun Sie dies automatisch einmal am Tag oder einmal in der Woche.
• Indizes neu erstellen
• Tabellen neu erstellen (bcp-Daten aus / ein)
• Dump / Reload der Datenbank (drastisch, kann aber Korruption beheben)
• Erstellen Sie einen neuen, angemesseneren Index
• Führen Sie DBCC aus, um festzustellen, ob die Datenbank möglicherweise beschädigt ist
• Schlösser / Deadlocks
  • Stellen Sie sicher, dass keine anderen Prozesse in der Datenbank ausgeführt werden
    • Besonders DBCC
  • Verwenden Sie das Sperren auf Zeilen- oder Seitenebene?
  • Sperren Sie die Tabellen ausschließlich, bevor Sie die Abfrage starten
  • Überprüfen Sie, ob alle Prozesse in derselben Reihenfolge auf Tabellen zugreifen
• Werden Indizes angemessen verwendet?
  • Joins verwenden nur dann einen Index, wenn beide Ausdrücke genau den gleichen Datentyp haben
  • Der Index wird nur verwendet, wenn die ersten Felder im Index in der Abfrage übereinstimmen
  • Werden gegebenenfalls Clustered-Indizes verwendet?
    • Bereichsdaten
    • WHERE-Feld zwischen Wert1 und Wert2
• Kleine Joins sind nette Joins
  • Standardmäßig berücksichtigt der Optimierer jeweils nur die Tabellen 4.
  • Dies bedeutet, dass bei Verknüpfungen mit mehr als 4 Tabellen eine gute Chance besteht, einen nicht optimalen Abfrageplan auszuwählen
• Brechen Sie den Join auf
  • Können Sie den Join auflösen?
  • Wählen Sie Fremdschlüssel in einer temporären Tabelle aus
  • Führen Sie die Hälfte des Joins aus und fügen Sie die Ergebnisse in eine temporäre Tabelle ein
• Verwenden Sie die richtige Art von temporärer Tabelle?
  • #tempTabellen sind möglicherweise viel leistungsfähiger als @tableVariablen mit großen Volumes (Tausende von Zeilen).
• Übersichtstabellen pflegen
  • Erstellen Sie mit Triggern für die zugrunde liegenden Tabellen
  • Bauen Sie täglich / stündlich / etc.
  • Ad-hoc erstellen
  • Inkrementell erstellen oder abbauen / neu erstellen
• Sehen Sie, was der Abfrageplan mit SET SHOWPLAN ON ist
• Sehen Sie, was mit SET STATS IO ON tatsächlich passiert
• Erzwinge einen Index mit dem Pragma: (Index: myindex)
• Erzwingen Sie die Tabellenreihenfolge mit SET FORCEPLAN ON
• Parameter Sniffing:
  • Teilen Sie die gespeicherte Prozedur in 2 auf
  • rufe proc2 von proc1 auf
  • Ermöglicht dem Optimierer, den Index in proc2 auszuwählen, wenn @parameter von proc1 geändert wurde
• Können Sie Ihre Hardware verbessern?
• Um wie viel Uhr rennst du? Gibt es eine ruhigere Zeit?
• Wird Replication Server (oder ein anderer Non-Stop-Prozess) ausgeführt? Kannst du es aussetzen? Führen Sie es z. stündlich?

1. Haben Sie eine ziemlich gute Vorstellung davon, wie die Abfrage in Ihrem Kopf optimal ausgeführt werden kann.
2. Überprüfen Sie den Abfrageplan - immer.
3. Aktivieren Sie STATS, damit Sie sowohl die E / A- als auch die CPU-Leistung überprüfen können. Konzentrieren Sie sich darauf, diese Zahlen zu verringern, nicht unbedingt auf die Abfragezeit (da dies durch andere Aktivitäten, Cache usw. beeinflusst werden kann).
4. Suchen Sie nach einer großen Anzahl von Zeilen, die in einen Operator eingehen, aber nach einer kleinen Anzahl, die herauskommt. Normalerweise hilft ein Index, indem er die Anzahl der eingehenden Zeilen begrenzt (wodurch Festplattenlesevorgänge gespeichert werden).
5. Konzentrieren Sie sich zuerst auf den größten Kosten-Teilbaum. Durch Ändern dieses Teilbaums kann häufig der gesamte Abfrageplan geändert werden.
6. Häufige Probleme, die ich gesehen habe, sind:
   • Wenn es viele Joins gibt, erweitert Sql Server manchmal die Joins und wendet dann WHERE-Klauseln an. Sie können dies normalerweise beheben, indem Sie die WHERE-Bedingungen in die JOIN-Klausel oder eine abgeleitete Tabelle mit den eingefügten Bedingungen verschieben. Ansichten können dieselben Probleme verursachen.
   • Suboptimale Verknüpfungen (LOOP vs HASH vs MERGE). Meine Faustregel lautet, einen LOOP-Join zu verwenden, wenn die obere Reihe im Vergleich zur unteren nur sehr wenige Zeilen enthält, einen MERGE, wenn die Sätze ungefähr gleich und geordnet sind, und einen HASH für alles andere. Durch Hinzufügen eines Join-Hinweises können Sie Ihre Theorie testen.
   • Parameter schnüffeln. Wenn Sie den gespeicherten Prozess zuerst mit unrealistischen Werten ausgeführt haben (z. B. zum Testen), ist der zwischengespeicherte Abfrageplan möglicherweise nicht optimal für Ihre Produktionswerte. Wenn Sie WITH RECOMPILE erneut ausführen, sollte dies überprüft werden. Für einige gespeicherte Prozesse, insbesondere für solche, die sich mit Bereichen unterschiedlicher Größe befassen (z. B. alle Daten zwischen heute und gestern - was eine INDEX-SUCHE bedeuten würde - oder alle Daten zwischen dem letzten Jahr und diesem Jahr -, die mit einem INDEX-SCAN besser dran wären ) Möglicherweise müssen Sie es jedes Mal WITH RECOMPILE ausführen.
   • Schlechte Einrückung ... Okay, SQL Server hat damit kein Problem - aber ich finde es sicher unmöglich, eine Abfrage zu verstehen, bis ich die Formatierung korrigiert habe.

Etwas abseits des Themas, aber wenn Sie die Kontrolle über diese Probleme haben ...
High Level und High Impact.

• Stellen Sie in Umgebungen mit hoher E / A sicher, dass Ihre Festplatten entweder für RAID 10 oder RAID 0 + 1 oder für eine verschachtelte Implementierung von RAID 1 und RAID 0 geeignet sind.
• Verwenden Sie keine Laufwerke mit weniger als 1500 KB.
• Stellen Sie sicher, dass Ihre Festplatten nur für Ihre Datenbank verwendet werden. IE keine Protokollierung kein Betriebssystem.
• Deaktivieren Sie die automatische Vergrößerung oder eine ähnliche Funktion. Lassen Sie die Datenbank den gesamten erwarteten Speicher verwenden. Nicht unbedingt das, was gerade verwendet wird.
• Entwerfen Sie Ihr Schema und Ihre Indizes für die Typabfragen.
• Wenn es sich um eine Protokolltyp-Tabelle handelt (nur Einfügen) und sich in der Datenbank befinden muss, indizieren Sie sie nicht.
• Wenn Sie viele Berichte erstellen (komplexe Auswahl mit vielen Verknüpfungen), sollten Sie ein Data Warehouse mit einem Stern- oder Schneeflockenschema erstellen.
• Haben Sie keine Angst davor, Daten im Austausch für Leistung zu replizieren!

CREATE INDEX

Stellen Sie sicher, dass für Sie Indizes verfügbar sind WHERE und JOINKlauseln sind. Dies beschleunigt den Datenzugriff erheblich.

Wenn Ihre Umgebung eine ist Data Mart oder ein Warehouse handelt, sollten für fast alle denkbaren Abfragen zahlreiche Indizes vorhanden sein.

In einer Transaktionsumgebung sollte die Anzahl der Indizes geringer und ihre Definitionen strategischer sein, damit die Indexpflege die Ressourcen nicht belastet. (Bei der Indexpflege müssen die Blätter eines Index geändert werden, um eine Änderung der zugrunde liegenden Tabelle wie bei INSERT, UPDATE,und widerzuspiegelnDELETE Operationen .)

Beachten Sie auch die Reihenfolge der Felder im Index - je selektiver (höhere Kardinalität) ein Feld ist, desto früher sollte es im Index erscheinen. Angenommen, Sie fragen nach gebrauchten Autos:

SELECT   i.make, i.model, i.price
FROM     dbo.inventory i
WHERE    i.color = 'red'
  AND    i.price BETWEEN 15000 AND 18000

Der Preis hat im Allgemeinen eine höhere Kardinalität. Möglicherweise sind nur ein paar Dutzend Farben verfügbar, aber möglicherweise Tausende verschiedener Preisvorstellungen.

idx01Bietet unter diesen Indexoptionen den schnelleren Pfad, um die Abfrage zu erfüllen:

CREATE INDEX idx01 ON dbo.inventory (price, color)
CREATE INDEX idx02 ON dbo.inventory (color, price)

Dies liegt daran, dass weniger Autos den Preis erfüllen als die Farbauswahl, sodass die Abfrage-Engine weitaus weniger Daten zu analysieren hat.

Es ist bekannt, dass zwei sehr ähnliche Indizes nur in der Feldreihenfolge unterschiedlich sind, um Abfragen (Vorname, Nachname) in einem und (Nachname, Vorname) in dem anderen zu beschleunigen.

Ein Trick, den ich kürzlich gelernt habe, ist, dass SQL Server sowohl lokale Variablen als auch Felder in einer Update-Anweisung aktualisieren kann.

UPDATE table
SET @variable = column = @variable + otherColumn

Oder die besser lesbare Version:

UPDATE table
SET
    @variable = @variable + otherColumn,
    column = @variable

Ich habe dies verwendet, um komplizierte Cursor / Joins bei der Implementierung rekursiver Berechnungen zu ersetzen, und habe auch viel an Leistung gewonnen.

Hier sind Details und Beispielcode, die zu fantastischen Leistungsverbesserungen geführt haben: http://geekswithblogs.net/Rhames/archive/2008/10/28/calculating-running-totals-in-sql-server-2005---the-optimal. aspx

Angenommen, MySQL hier, verwenden Sie EXPLAIN, um herauszufinden, was mit der Abfrage passiert, stellen Sie sicher, dass die Indizes so effizient wie möglich verwendet werden, und versuchen Sie, Dateisortierungen zu beseitigen. Hochleistungs-MySQL: Optimierung, Backups, Replikation und mehr ist ein großartiges Buch zu diesem Thema, ebenso wie MySQL Performance Blog .

@ Terrapin Es gibt noch ein paar andere Unterschiede zwischen isnull und coalesce, die erwähnenswert sind (neben der ANSI-Konformität, die für mich sehr wichtig ist).

Koaleszenz gegen IsNull

Wenn Sie in SQL Server ein ODER in einer where-Klausel verwenden, wird die Leistung manchmal erheblich beeinträchtigt. Anstatt den OP zu verwenden, wählen Sie einfach zwei aus und verbinden Sie sie miteinander. Sie erhalten die gleichen Ergebnisse bei 1000-facher Geschwindigkeit.

Schauen Sie sich die where-Klausel an - überprüfen Sie die Verwendung von Indizes / überprüfen Sie, ob nichts Dummes getan wird

where SomeComplicatedFunctionOf(table.Column) = @param --silly

Ich beginne im Allgemeinen mit den Joins - ich werde jeden einzelnen einzeln aus der Abfrage streichen und die Abfrage erneut ausführen, um eine Vorstellung davon zu bekommen, ob es einen bestimmten Join gibt, mit dem ich ein Problem habe.

In all meinen temporären Tabellen möchte ich (falls zutreffend) eindeutige Einschränkungen hinzufügen, um Indizes und Primärschlüssel (fast immer) zu erstellen.

declare @temp table(
    RowID int not null identity(1,1) primary key,
    SomeUniqueColumn varchar(25) not null,
    SomeNotUniqueColumn varchar(50) null,
    unique(SomeUniqueColumn)
)

Ich habe es mir zur Gewohnheit gemacht, immer Bindungsvariablen zu verwenden. Es ist möglich, dass Bindungsvariablen nicht helfen, wenn das RDBMS keine SQL-Anweisungen zwischenspeichert. Wenn Sie jedoch keine Bindevariablen verwenden, hat das RDBMS keine Möglichkeit, Abfrageausführungspläne und analysierte SQL-Anweisungen wiederzuverwenden. Die Einsparungen können enorm sein: http://www.akadia.com/services/ora_bind_variables.html . Ich arbeite hauptsächlich mit Oracle, aber Microsoft SQL Server funktioniert fast genauso.

Nach meiner Erfahrung sind Sie es wahrscheinlich nicht, wenn Sie nicht wissen, ob Sie Bindungsvariablen verwenden oder nicht. Wenn Ihre Anwendungssprache sie nicht unterstützt, suchen Sie eine, die dies unterstützt. Manchmal können Sie Abfrage A beheben, indem Sie Bindungsvariablen für Abfrage B verwenden.

Danach spreche ich mit unserem DBA, um herauszufinden, was das RDBMS am meisten schmerzt. Beachten Sie, dass Sie nicht fragen sollten: "Warum ist diese Abfrage langsam?" Das ist so, als würden Sie Ihren Arzt bitten, Ihren Anhang herauszunehmen. Sicher, Ihre Anfrage könnte das Problem sein, aber es ist genauso wahrscheinlich, dass etwas anderes schief geht. Als Entwickler neigen wir dazu, in Codezeilen zu denken. Wenn eine Linie langsam ist, korrigieren Sie diese Linie. Ein RDBMS ist jedoch ein wirklich kompliziertes System, und Ihre langsame Abfrage kann das Symptom eines viel größeren Problems sein.

Viel zu viele SQL-Tuning-Tipps sind Idole des Frachtkultes. In den meisten Fällen hängt das Problem nicht oder nur minimal mit der von Ihnen verwendeten Syntax zusammen. Daher ist es normalerweise am besten, die sauberste Syntax zu verwenden, die Sie können. Anschließend können Sie nach Möglichkeiten suchen, die Datenbank (nicht die Abfrage) zu optimieren. Passen Sie die Syntax nur an, wenn dies fehlschlägt.

Sammeln Sie wie bei jeder Leistungsoptimierung immer aussagekräftige Statistiken. Verwenden Sie keine Wanduhrzeit, es sei denn, es ist die Benutzererfahrung, die Sie einstellen. Schauen Sie sich stattdessen Dinge wie CPU-Zeit, abgerufene Zeilen und von der Festplatte abgelesene Blöcke an. Zu oft optimieren die Leute für das Falsche.

Erster Schritt: Sehen Sie sich den Abfrageausführungsplan an!
TableScan -> schlechte
NestedLoop -> meh Warnung
TableScan hinter einer NestedLoop -> DOOM!

SET STATISTICS IO ON
SET STATISTICS TIME ON

Das Ausführen der Abfrage mit WITH (NoLock) ist an meiner Stelle so ziemlich Standard. Jeder, der beim Ausführen von Abfragen an den 10-Gigabyte-Tabellen erwischt wurde, ohne dass diese herausgenommen und erschossen wurden.

Konvertieren Sie NOT IN-Abfragen nach Möglichkeit in LEFT OUTER JOINS. Wenn Sie beispielsweise alle Zeilen in Tabelle 1 suchen möchten, die von einem Fremdschlüssel in Tabelle 2 nicht verwendet werden, können Sie Folgendes tun:

SELECT *
FROM Table1
WHERE Table1.ID NOT IN (
    SELECT Table1ID
    FROM Table2)

Aber Sie erhalten damit eine viel bessere Leistung:

SELECT Table1.*
FROM Table1
LEFT OUTER JOIN Table2 ON Table1.ID = Table2.Table1ID
WHERE Table2.ID is null

@ DavidM

Angenommen, MySQL hier, verwenden Sie EXPLAIN, um herauszufinden, was mit der Abfrage los ist, und stellen Sie sicher, dass die Indizes so effizient wie möglich verwendet werden ...

In SQL Server erhalten Sie mit dem Ausführungsplan dasselbe: Er zeigt Ihnen, welche Indizes betroffen sind usw.

Indizieren Sie die Tabelle (n) nach den Clms, nach denen Sie filtern

Nicht unbedingt ein SQL-Leistungstrick an sich, aber definitiv verwandt:

Eine gute Idee wäre, wenn möglich memcached zu verwenden, da es viel schneller wäre, die vorkompilierten Daten direkt aus dem Speicher abzurufen, als sie aus der Datenbank abzurufen. Es gibt auch eine Variante von MySQL, die in Memcached integriert wurde (von Drittanbietern).

Stellen Sie sicher, dass Ihre Indexlängen so klein wie möglich sind. Auf diese Weise kann die Datenbank mehr Schlüssel gleichzeitig aus dem Dateisystem lesen und so Ihre Joins beschleunigen. Ich gehe davon aus, dass dies mit allen DBs funktioniert, aber ich weiß, dass dies eine spezifische Empfehlung für MySQL ist.

Ich achte auf:

• Rollen Sie alle CURSOR-Schleifen ab und konvertieren Sie sie in satzbasierte UPDATE / INSERT-Anweisungen.
• Achten Sie auf Anwendungscode, der:
  • Ruft einen SP auf, der eine große Anzahl von Datensätzen zurückgibt.
  • Durchläuft dann in der Anwendung jeden Datensatz und ruft einen SP mit Parametern auf, um Datensätze zu aktualisieren.
  • Konvertieren Sie dies in einen SP, der die gesamte Arbeit in einer Transaktion erledigt.
• Jeder SP, der viele Zeichenfolgen manipuliert. Es ist ein Beweis dafür, dass die Daten nicht korrekt strukturiert / normalisiert sind.
• Alle SPs, die das Rad neu erfinden.
• Alle SPs, die ich nicht verstehen kann, was sie innerhalb einer Minute versuchen!

SET NOCOUNT ON

Normalerweise die erste Zeile in meinen gespeicherten Prozeduren, es sei denn, ich muss sie tatsächlich verwenden @@ROWCOUNT.

Verwenden Sie in SQL Server die Anweisung nolock. Damit kann der Befehl select ausgeführt werden, ohne warten zu müssen - normalerweise werden andere Transaktionen abgeschlossen.

SELECT * FROM Orders (nolock) where UserName = 'momma'

Entfernen Sie die Cursor überall dort, wo dies nicht erforderlich ist.

Entfernen Sie Funktionsaufrufe in Sprocs, in denen viele Zeilen die Funktion aufrufen.

Mein Kollege verwendete Funktionsaufrufe (als Beispiel lastlogindate von userid), um sehr breite Datensätze zurückzugeben.

Mit der Optimierung beauftragt, habe ich die Funktionsaufrufe im Sproc durch den Funktionscode ersetzt: Ich habe die Laufzeit vieler Sprocs von> 20 Sekunden auf <1 gesenkt.

• Stellen Sie allen Tabellen dbo voran. um Neukompilierungen zu verhindern.
• Zeigen Sie Abfragepläne an und suchen Sie nach Tabellen- / Index-Scans.
• Durchsuchen Sie 2005 die Verwaltungsansichten nach fehlenden Indizes.

Ich benutze gerne

isnull(SomeColThatMayBeNull, '')

Über

coalesce(SomeColThatMayBeNull, '')

Wenn ich die Unterstützung mehrerer Argumente, die Ihnen die Koaleszenz bietet, nicht benötige.

http://blog.falafel.com/2006/04/05/SQLServerArcanaISNULLVsCOALESCE.aspx

Stellen Sie gespeicherten Prozedurnamen nicht "sp_" voran, da alle Systemprozeduren mit "sp_" beginnen und SQL Server beim Aufrufen Ihrer Prozedur härter suchen muss, um Ihre Prozedur zu finden.

Schmutzig liest -

set transaction isolation level read uncommitted

Verhindert tote Sperren, bei denen die Transaktionsintegrität nicht unbedingt erforderlich ist (was normalerweise der Fall ist).

Ich gehe immer zuerst zum SQL Profiler (wenn es sich um eine gespeicherte Prozedur mit vielen Verschachtelungsebenen handelt) oder zum Abfrageausführungsplaner (wenn es sich um einige SQL-Anweisungen ohne Verschachtelung handelt). In 90% der Fälle können Sie das Problem sofort mit einem dieser beiden Tools finden.