Bei der Arbeit hatten wir eine Abfrage zu einer Tabelle mit folgender Struktur:
%Vor%Diese Tabelle hatte ca. 6,1 Millionen Zeilen.
Um die Details für eine bestimmte IP-Adresse herauszufinden, haben wir eine Abfrage wie die folgende verwendet:
%Vor% Bei Oracle 10 in unserer Dev-Datenbank dauerte dies etwa 17 Sekunden, um eine Zeile zurückzugeben, abhängig von der ip_num , die übergeben wurde. Auf unserem leistungsstärkeren Live-System dauerte es vielleicht 5-6 Sekunden, was noch zu langsam war Echtzeit und wir mussten dies über einen Hintergrundjob auswählen.
Nicht ideal, zumal unsere Echtzeit-Systeme die IP-Details wirklich brauchten.
Der verwendete Indextyp war ein Standard-BTREE-Index, der sowohl ip_from als auch ip_to überspannte. Wir haben uns viele Dinge angeschaut, um zu versuchen, dies zu beschleunigen, wie zB die Bereichspartitionierung . Wir haben das am Ende nicht angewendet, da Oracle Enterprise erforderlich ist. Wir haben auch versucht, die Parallelität der Tabelle zu erhöhen, aber das hatte keine merkliche Auswirkung.
Jedenfalls habe ich bei meinem morgendlichen Kaffee bemerkt, dass ich dachte, dass es eine Leistungsverbesserung geben könnte, indem ich die folgende Abfrage durchführe: (Dies ist aus dem Speicher, es könnte ein paar Fehler geben. Auch einzelne Felder wurden nicht ausgewählt)
%Vor% Dies funktioniert für unseren Datensatz, da es keine überlappenden Bereiche zwischen ip_from und ip_to gibt.
Allerdings war ich nicht darauf vorbereitet, wie viel schneller die zweite Abfrage ist. Die Zeit in unserer Entwicklungsdatenbank wurde von 17 Sekunden auf 0,007 Sekunden reduziert.
Das macht wenig Sinn für mich. Ich würde eine Leistungssteigerung erwarten, aber nicht so viel. Sollten die Datenbankstatistiken nicht herausgefunden haben, gibt es keine Überlappung und entsprechend optimiert? Außerdem muss es einen schnelleren Weg zur Auswahl von Bereichen geben?
Meine Frage ist: Warum ist die zweite Abfrage so viel schneller, selbst wenn Sie eine Unterauswahl verwenden?
Die Leistungssteigerung ist offensichtlich. Weil es einen Index auf ip_from gibt, so kann max (ip_from) in konstanter Zeit erhalten werden, weil, wie Sie wissen, die Indexierung die Werte aussortiert. Der Bereich ist auch leicht zu berechnen, weil die Suche über den btree binär ist.
während in der vorherigen Abfrage eine Tabellenüberprüfung aller Daten durchgeführt werden muss, um die Bereichsgrenzen zu berechnen
Tags und Links sql optimization range