PostgreSQL - Abfrageoptimierung

Wenn wir Multiples machen Anfragen In einem komplexen System gehen wir oft nicht den richtigen Weg, um auf Datenbankebene eine optimale Leistung zu erzielen, mit dem aktuellen technologischen Fortschritt und der Rechenleistung, die wir oft in unseren Servern sehen, können wir denken, dass die Datenbankoptimierung der Vergangenheit angehören.
Dies könnte nicht weiter von der Wahrheit entfernt sein, trotz der Weiterentwicklung der Geräte sind die Datenbanken von grundlegender Bedeutung für die Leistung der Anwendungen, aus diesem Grund kann eine gut geschriebene und hochoptimierte Abfrage mehrere Sekunden Last bedeuten, die Sie sparen das System, wenn wir dies mit der Anzahl der gleichzeitigen Benutzer multiplizieren, sehen wir, wie Kosten und Strom verschwendet wurden.
Abfragen optimieren
Der beste Weg, um die Leistung unserer Datenbanken zu verbessern, besteht darin, mit gut geschriebenen Abfragen zu beginnen. Oft stellen wir fest, dass die Abfragen nicht gut geschrieben sind, da sie nicht so optimiert sind, wie sie sein sollten. Dafür gibt es viele Ursachen, eine davon ist die Wiederverwendung ohne Code-Awareness; Damit meinen wir, dass wir, wenn wir irgendwann eine Abfrage gemacht haben, die für uns funktioniert mit a links beitreten Wir werden es weiterhin anwenden, wenn wir die Anzahl der abzufragenden Tabellen erhöhen, wenn wir es modifizieren und einige Klauseln ändern um innere Verbindung Es könnte den Weg verkürzen und den Prozessorverbrauch einsparen.
SQL ist eine Sprache, die zwar recht einfach zu lesen ist, aber viele Aspekte und viele Variationen hat, die es uns ermöglichen, etwas zu tun, das am besten und am schlechtesten funktioniert. Es liegt an uns zu wissen, ob unsere Lösung zu gehört eine Kategorie oder so.
Um zu wissen, dass wir auf dem richtigen Weg sind, ist eines der wichtigsten Dinge zu aktualisieren, d PostgreSQL als wäre es die erste version, wenn wir in der Version 9.
Über die Verwendung von Unterabfragen
Dies ist einer der häufigsten Fehler, die wir machen, und das ist, dass wir uns eine Abfrage als eine Reihe von Teilen vorstellen, die wir zusammenfügen, bis wir ein Endergebnis erhalten. Dieses Verhalten hat jedoch einen großen Einfluss auf die Leistung unserer Datenbank.
Sehen wir uns ein Beispiel für dieses typische Verhalten an:

 SELECT tract_id, (SELECT COUNT (*) FROM census.facts As F WHERE F.tract_id = T.tract_id) As num_facts, (SELECT COUNT (*) FROM census.lu_fact_types As Y WHERE Y.fact_type_id IN (SELECT fact_type_id FROM census. Fakten F WHERE F.tract_id = T.tract_id)) Als num_fact_types FROM census.lu_tracts Als T; 

Wenn wir nun den Graphen der ERKLÄREN Anhand dieser Abfrage werden wir erkennen, wie teuer es ist, dies auf diese Weise zu tun:

VERGRÖSSERN

Wie wir sehen, haben wir einige Engpässe in dieser Abfrage, abgesehen von all den Daten, die ineffizient verschoben werden müssen, dafür werden wir sie optimal umschreiben und mit einem neuen Graphen der vergleichen ERKLÄREN.

 SELECT T.tract_id, COUNT (f.fact_type_id) Als num_facts, COUNT (DISTINCT fact_type_id) Als num_fact_types FROM census.lu_tracts Als T LEFT JOIN census.facts Als F ON T.tract_id = F.tract_id GROUP BY T.tract_id; 

In dieser neuen Version unserer Abfrage vermeiden wir die Verwendung von Unterabfragen, stattdessen machen wir ein Äquivalent mit links beitreten Ja gruppiere nachWenn wir die Grafik sehen, können wir den Unterschied erkennen.

VERGRÖSSERN

Wir sehen, dass der Weg zu unserem Ergebnis viel kürzer ist, was uns eine höhere Leistung bringt. Damit meinen wir nicht, dass wir die Unterabfragen unserer Arbeitswerkzeuge ausschließen müssen, sondern müssen uns bewusst sein, dass sie möglicherweise gibt es bessere Wege für das, was wir derzeit vorschlagen.Hat dir dieses Tutorial gefallen und geholfen?Sie können den Autor belohnen, indem Sie diesen Knopf drücken, um ihm einen positiven Punkt zu geben