tablestudioapp/plugins

Abfragen mit TableStudio schneller machen

TableStudio misst, nicht nur rät. Empfehle niemals einen Index oder eine Neuschreibung aus dem Bauch heraus, wenn du es mit den unten stehenden Werkzeugen belegen kannst. Die meisten davon sind PostgreSQL-exklusiv; bei anderen Datenbank-Engines verwende explain_query und leite aus dem Ausführungsplan ab.

Wähle zuerst die Verbindung aus, wie im Skill für Datenbank-Workflows beschrieben. Bevorzuge die Analyse einer Datenbank mit realistischen Daten. Eine fast leere Entwicklungsdatenbank liefert irreführende Pläne.

Finden, was langsam ist

• Der Benutzer nennt eine Abfrage oder einen Endpunkt: Finde das SQL, das ausgeführt wird (aus dem Code oder dem ORM-Log), und gehe dann zu "Einzelne Anweisung diagnostizieren".
• "Warum ist die Datenbank langsam?" Rufe slow_queries auf. Es sortiert die Anweisungen nach Gesamtzeit aus pg_stat_statements. Behalte die query_id jeder Zeile; die anderen Werkzeuge akzeptieren sie. Falls die Erweiterung nicht installiert ist, erklärt das Werkzeug, was für die Aktivierung nötig ist; gib das weiter, anstatt sie ungefragt zu installieren.
• Allgemeine Optimierung: workload_index_advisor findet die wenigsten Indizes, die die meiste Datenbankzeit abdecken, und listet vorhandene Indizes auf, die nie verwendet werden.

Ein Gesundheitscheck

Wenn der Benutzer fragt, was mit einer Datenbank nicht stimmt, oder eine allgemeine Überprüfung wünscht, ändere nichts und berichte:

1. database_health. Lies die unavailable-Liste, bevor du zusammenfasst: Ein leeres Ergebnis mit Einträgen dort bedeutet, dass Prüfungen übersprungen wurden, nicht dass alles in Ordnung ist.
2. database_overview für Größe, die größten und am stärksten beanspruchten Tabellen sowie Verbindungszahlen.
3. schema_issues (ohne table) für Designprobleme in der gesamten Datenbank.

Setze die wichtigsten Erkenntnisse an den Anfang, in verständlicher Sprache: Was das Problem ist, was es kostet, wenn es ignoriert wird, und die Lösung. Füge das verify_sql jeder Erkenntnis bei, damit der Benutzer die Zahl überprüfen kann, sowie die lock_impact-Angabe jeder Lösung. Biete an, die vom Benutzer ausgewählten Lösungen über "Ausliefern" umzusetzen.

Einzelne Anweisung diagnostizieren

1. optimize_query mit dem SQL (und der query_id, falls es von slow_queries stammt). Für eine schreibgeschützte Anweisung übergib analyze: true, damit die gemessenen Prüfungen laufen können. Es wird einmal innerhalb einer zurückgerollten Transaktion ausgeführt. Es meldet already_fast, wenn es nichts zu tun gibt; sag das so, anstatt eine Verbesserung zu erfinden.
2. Für mehr Details verwende explain_query (analyze: true nur für Lesezugriffe). Vergleiche actual_rows mit estimated_rows auf jedem Knoten. Eine große Abweichung bedeutet veraltete Statistiken (ANALYZE auf der Tabelle), was oft der eigentliche Fehler ist und kein fehlender Index.
3. Eine Anweisung mit Platzhaltern $1, $2 benötigt echte Werte für einen korrekten Plan. suggest_parameter_values findet diese aus Verlauf, laufenden Sitzungen und Statistiken.

Die Lösung belegen

Verwende benchmark_query_variants (das Query Lab), bevor du etwas empfiehlst:

• Gib das Basis-SQL und die Kandidaten als variants an: ein neu geschriebenes sql, hypothetical_indexes (mit hypopg geplant, nie erstellt), hide_indexes oder Planner-settings. Oder lasse variants weg und lasse find_faster eigene Vorschläge generieren.
• Es meldet Mediane über mehrere Durchläufe für jeden Parametersatz und prüft, ob jede Neuschreibung die gleichen Zeilen wie die Basisabfrage zurückgibt.
• Empfehle nur eine Variante, deren same_rows "yes" ist. Bevorzuge die Variante in recommendation. Zitiere die gemessenen Werte vorher und nachher, keine Prozentzahlen aus dem Bauch heraus.

Vor dem Entfernen eines Index (ungenutzt oder doppelt) führe index_what_if mit diesem Index in hide aus. Jede Anweisung, die dadurch teurer wird oder den Index heute nutzt, wäre betroffen.

Ausliefern

Indizes und Neuschreibungen durchlaufen den normalen Änderungsablauf aus dem Skill für Datenbank-Workflows:

• Indexänderungen sind Schemaänderungen. Falls das Repository ein Migrations-Tool hat, füge den Index dort hinzu. Andernfalls schlage ihn mit stage_migration vor und füge die gemessenen Zahlen in die rationale ein.
• Bei PostgreSQL verwende CREATE INDEX CONCURRENTLY für jede Tabelle, die Datenverkehr sieht, und schließe es nicht in eine Transaktion ein.
• Eine Abfrageneuschreibung ist eine Codeänderung: Bearbeite den Code, der die Abfrage ausführt, und erwähne das Benchmark-Ergebnis in deiner Zusammenfassung.