Finden Sie die teure Anfrage, bevor Sie die Datenbank ändern
Starten Sie an einer Nutzeraktion: Kategorieseite laden, Artikelsuche, in den Warenkorb legen oder Bestellung absenden. Erfassen Sie die Route, Anzahl der Abfragen, Datenbankdauer, zurückgegebene Zeilen und Gesamtdauer der Anfrage. Eine langsame Seite kann auch auf Anwendungslogik oder eine andere Abhängigkeit warten; diagnostizieren Sie nicht nur anhand der Seitenladezeit.
Ein Abfrageplan ist der Datenbankpfad durch Tabellen, Indizes, Joins, Sortierungen und Aggregationen. In PostgreSQL zeigt EXPLAIN diesen Pfad. EXPLAIN ANALYZE führt die Anweisung aus und meldet tatsächliche Zeilen und Zeiten; verwenden Sie eine sichere, repräsentative Abfrage. Eine große Lücke zwischen geschätzten und tatsächlichen Zeilen ist ein Grund, Statistiken oder Bedingungen zu untersuchen, aber nicht automatisch ein Index-Antrag.
Verknüpfen Sie eine Kandidatenabfrage mit einer Route und einem Ergebnis, damit ein reines Dashboard-Report nicht einen langsamen Checkout überdeckt.
Protokollieren Sie Messwerte vor der Änderung und vergleichbaren Traffic, ohne Kundenkennungen, Tokens oder kartenbezogene Werte zu loggen.
Entwerfen Sie Indizes für den tatsächlich genutzten Zugriffspfad
Ein Index ist eine gepflegte Struktur, die beim Auffinden von Zeilen oder beim Zurückgeben in Reihenfolge helfen kann; er ist kein universeller Geschwindigkeitshebel. Beginnen Sie mit den Filtern, Join-Schlüsseln und der Sortierung einer wichtigen Abfrage und bestätigen Sie den vorgeschlagenen Index im Plan. PostgreSQL dokumentiert, dass ein passender B-tree-Index ORDER BY ohne separaten Sortiervorgang erfüllen kann, insbesondere mit kleinem LIMIT.
Indizes verursachen zusätzlichen Speicherbedarf und Schreibarbeit, weil Inserts, Updates und Deletes sie pflegen. Für eine Abfrage, die einen großen Teil einer Tabelle benötigt, kann ein sequentieller Scan mit expliziter Sortierung schneller sein. Testen Sie an produktionsähnlichen Daten und behalten Sie einen Index nur, wenn der Nutzen seine Kosten rechtfertigt.
Nutzen Sie die tatsächlichen Filter und ORDER BY der Abfrage, einschließlich eines deterministischen Tie-Breakers, wenn die Oberfläche eine stabile Reihenfolge braucht.
Prüfen Sie, ob ein Index genutzt wird und welche Schreibkosten er verursacht; überprüfen Sie dies erneut, wenn sich Daten und Traffic ändern.
Machen Sie Paginierung stabil und erschwinglich
Seitenzahl-Paginierung verwendet meist LIMIT plus OFFSET. Legen Sie immer eine vorhersehbare Reihenfolge fest. PostgreSQL warnt, dass ohne ORDER BY LIMIT eine unvorhersehbare Teilmenge zurückgeben kann; unterschiedliche LIMIT- oder OFFSET-Werte können inkonsistente Mengen liefern, weil der Optimizer verschiedene Pläne wählen kann.
Große Offsets verdienen Aufmerksamkeit, weil übersprungene Zeilen trotzdem berechnet werden müssen. Für tiefes Browsen in Katalogen, Bestellverläufen oder Archiven sollten Sie Cursor- oder Keyset-Paginierung in Betracht ziehen: Fordern Sie Zeilen nach dem zuletzt gesehenen stabilen Sortierwert und einem eindeutigen Tie-Breaker an. Definieren Sie, wie neue oder gelöschte Datensätze erscheinen, bevor Sie die Oberfläche ändern.
Geben Sie die kleinstmögliche nützliche Seite zurück, anstatt ein unbeschränktes Resultat.
Entscheiden Sie, ob die Oberfläche wirklich bei jeder Anfrage eine exakte Gesamtanzahl benötigt.
Cachen Sie Lesearbeit, ohne falsche Antworten zu liefern
Caching verwendet ein vorheriges Ergebnis, statt es aus der Datenbank neu zu konstruieren. Beginnen Sie auf HTTP-Ebene für öffentliche, wiederholbare Seiten und versionierte Assets, weil ein Cache-Hit sowohl Applikations- als auch Datenbankarbeit vermeiden kann. web.dev empfiehlt langlebiges Caching für versionierte URLs; das Ändern der URL ist der praktische Invalidation-Mechanismus.
Cache-Policy ist eine Korrektheitsentscheidung. Ein geteilter Cache kann eine Antwort über Nutzer hinweg wiederverwenden, also teilen Sie keine Account-, Warenkorb-, Preis- oder autorisierungsspezifischen Ausgaben, es sei denn, sie sind dafür entworfen und getestet. Cache-Control private schränkt die Wiederverwendung auf den Browser-Cache ein, während no-store Caches anweist, nichts zu behalten.
Trennen Sie öffentliche Katalog- oder Artikelausgaben von sitzungsspezifischen, standortabhängigen und berechtigungsabhängigen Ausgaben.
Definieren Sie, wer welchen veralteten Wert sehen darf, wie lange und welchen Invalidierungs- oder Revalidierungspfad es gibt.
Schützen Sie Verbindungs-Kapazität statt einfach das Limit zu erhöhen
Eine Verbindung ist eine aktive Clientsitzung zur Datenbank. Worker, Cron-Jobs, Previews oder Retries können Slots erschöpfen, selbst wenn einzelne Abfragen akzeptabel erscheinen. PostgreSQLs max_connections steuert gleichzeitige Verbindungen, wird beim Serverstart gesetzt und ein höherer Wert reserviert mehr Ressourcen einschließlich Shared Memory. Ihn ohne Arbeitslastmodell anzuheben, kann das Versagen nur verlagern.
Setzen Sie ein Budget über Web-Worker, Hintergrundjobs, Administration und Replikate hinweg. Nutzen Sie bounded pooling, wo es passt, bewahren Sie Spielraum für die Wiederherstellung und setzen Sie Timeouts, damit feststeckende Arbeit nicht endlos wartet. Sichere Zahlen hängen vom Engine-Typ, Speicher, Abfragemix und Provider-Limits ab; bestätigen Sie sie mit dem Betreiber.
Beziehen Sie Webprozesse, Queues, geplante Aufgaben, Migrationen, Reporting-Tools und Deployment-Jobs ein.
Begrenzen Sie die Parallelität und nutzen Sie Backoff, damit ein Fehler die Verbindungsnachfrage nicht vervielfacht.
Beobachten Sie Abfragekosten mit Kontext- und Datenschutzkontrollen
Rangieren Sie Datenbankarbeit nach Gesamtauswirkung, nicht nach einer einzigen langsamen Stichprobe. Eine mäßig langsame Abfrage, die tausendfach ausgeführt wird, kann wichtiger sein als ein seltener Bericht. PostgreSQLs pg_stat_statements aggregiert Planung und Ausführungsdaten einschließlich Aufrufen, Gesamt- und Mittelzeit, Zeilen und Buffer-Aktivität. Es benötigt Serverkonfiguration und einen Neustart zum Hinzufügen oder Entfernen; Planungs-Tracking kann Overhead hinzufügen.
Verbinden Sie Abfragegruppen mit Route, Release-Version und Zeitfenster. OpenTelemetry empfiehlt, Abfrage-Text standardmäßig nur nach Sanitizing zu sammeln, wobei Literale ersetzt werden, und eine niedrig-kardinale Abfragezusammenfassung zur Gruppierung zu verwenden. Das hilft Teams, Trends zu sehen, ohne Kundendaten zu exportieren oder für jeden Wert ein Label zu erzeugen.
Überprüfen Sie Dauer, Gesamtzeit, Aufrufe, Fehler, Verbindungen und Zeilen; jeder zeigt eine andere Fehlerart auf.
Verwenden Sie parametrische Abfragen und prüfen Sie, dass Literale entfernt werden, bevor Traces oder Logs die Anwendung verlassen.
Liefern Sie Datenbankänderungen als umkehrbare Zuverlässigkeitsarbeit aus
Behandeln Sie einen Index, eine Umschreibung, Cache-Policy, Pool-Einstellung oder Schemaänderung als Produktionsänderung mit einem Eigentümer, Erfolgsmaß und Rollback-Entscheidung. Validieren Sie in einer repräsentativen Umgebung, rollen Sie an eine begrenzte Teilmenge aus und überwachen Sie die betroffene Reise. Schneller ist kein Erfolg, wenn die Änderung falsche, fehlende, doppelte oder veraltete Daten zurückliefert.
Schemaänderungen erfordern Vorsicht, weil Anwendungs-Versionen überlappen können. Google Cloud Guidance beschreibt eine Kompatibilitätssequenz: Veröffentlichen Sie eine Anwendung, die altes und neues Schema verarbeiten kann, ändern Sie das Schema und stellen Sie dann das Feature bereit, das es nutzt. Das bewahrt eine Anwendungs-Rollback-Route. Locking- und Online-Change-Verhalten unterscheiden sich je nach Engine und Managed Service; holen Sie fachkundige Prüfung für hochvolumige oder zahlungsrelevante Systeme ein.
Nennen Sie die Route, Performance- und Korrektheitssignale sowie die Schwelle, die den Rollout stoppt.
Verifizieren Sie Performance und Korrektheit in einer kontrollierten Teilmenge, bevor Sie ausweiten; üben Sie den Rückweg außerhalb eines Incidents.