Ich mache die folgenden zwei Abfragen ziemlich häufig in einer Tabelle, die im Wesentlichen Logging-Informationen sammelt. Beide wählen unterschiedliche Werte aus einer großen Anzahl von Zeilen aus, aber mit weniger als 10 verschiedenen Werten in diesen.
Ich habe beide "unterschiedliche" Anfragen analysiert, die auf der Seite gemacht wurden:
%Vor%Beide tun Sequenz-Scans der Spalten. Wenn ich jedoch enable_seqscan ausschalte (obwohl der Name nur das Ausführen von Sequenz-Scans für Spalten mit Indizes deaktiviert), verwendet die Abfrage den Index, ist aber noch langsamer:
%Vor%Sowohl bundle_id- als auch server_name-Spalten haben btree-Indizes, sollte ich einen anderen Indextyp verwenden, um die Auswahl bestimmter Werte schnell zu machen?
Sie wählen eindeutige Werte aus der gesamten Tabelle aus, was automatisch zu einem Seq-Scan führt. Sie haben Millionen Zeilen, also wird es langsam sein.
Es gibt einen Trick, um die verschiedenen Werte schneller zu bekommen, aber es funktioniert nur, wenn die Daten einen bekannten (und vernünftig kleinen) Satz möglicher Werte haben. Zum Beispiel nehme ich an, dass Ihre bundle_id eine Art Bundles-Tabelle referenziert, die kleiner ist. Das bedeutet, Sie können schreiben:
%Vor%Dies sollte zu einem verschachtelten Loop / Seq-Scan für Bundles führen - & gt; index scan auf audit_records mit dem index auf bundle_id.
Ich habe das gleiche Problem mit Tabellen & gt; 300 Millionen Datensätze und ein indiziertes Feld mit einigen eindeutigen Werten. Ich konnte den Seq-Scan nicht loswerden, also habe ich diese Funktion gemacht, um eine eindeutige Suche unter Verwendung des Indexes zu simulieren, falls er existiert. Wenn Ihre Tabelle mehrere unterschiedliche Werte proportional zur Gesamtzahl der Datensätze hat, ist diese Funktion nicht gut. Es muss auch für mehrspaltige eindeutige Werte angepasst werden. Warnung : Diese Funktion ist für SQL-Injection weit offen und sollte nur in einer gesicherten Umgebung verwendet werden.
Erklären Sie Analyseergebnisse:
Abfrage mit normalem SELECT DISTINCT: Gesamtlaufzeit: 598310.705 ms
Abfrage mit SELECT small_distinct (...): Gesamtlaufzeit: 1.156 ms
Anrufbeispiele:
%Vor%Auf PostgreSQL 9.3, ausgehend von der Antwort von Denis:
%Vor%nur durch Hinzufügen einer 'Grenze 1' zur Unterabfrage, habe ich eine 60x Beschleunigung (für meinen Anwendungsfall, mit 8 Millionen Datensätzen, einem zusammengesetzten Index und 10k Kombinationen), von 1800ms bis 30ms:
%Vor%Tags und Links postgresql