Performancefrage

[ChrisE]

Hallo,

ich habe eine Tabelle Messungen in der sind verschiedene Informationen zu Messungen abgelegt :-) Unter anderem auch der Startzeitpunkt als TIMESTAMP. Wenn ich jetzt die jüngste Messung haben möchte würde ich folgenden Select machen:

Code:

SELECT bla, blub, tralla FROM Messungen WHERE Startzeit = (select MAX(Startzeit) from Messungen);

Über den PrimeryKey ID: Integer kann ich nicht gehen, da die Messungen nicht zwingend chronologisch in der Datenbank abgelegt werden.

So, jetzt meine Fragen:

• Gibt es eine Performantere Lösung (nur Select anpassen) für die Problemstellung?
• Wenn man einen Index auf die Startzeit legen würde, würde es die Abfragegeschwindigkeit verbessern? (wobei ich nochmal klären sollte, ob es mehrere Messungen geben kann, die den selben Zeitpunkt haben. Aber das gilt für die gesammte Fragestellung ;-) )
• Ändert es etwas an der Performance wenn man es in eine SP packt, oder ist die SELECT-Anweisung dafür zu simpel/klein?

Danke, Chris

P.S.: Gibt es eigentlich keine SQL-Tags?

[mkinzler]

SQL-Code:

SELECT bla, blub, tralla FROM Messungen WHERE Startzeit = ( select first 1 startzeit from Messungen order by startzeit desc);

Hierfür am Besten noche einen Index auf der Spalte Startzeit

BTW. SQL-Formatierung geht als Erweiterung des CODE-Tags (=SQL)

[WladiD]

Hi Chris,

Sub-Selects sind IMHO nicht so performant wie andere Lösungen. Man sollte möglichst auf die verzichten. Deine Abfrage würde ich wie folgt umschreiben:

Code:

SELECT FIRST 1 bla, blub, tralla FROM Messungen ORDER BY Startzeit DESC

Ohne einen Index muss sowohl für "MAX(Startzeit)" als auch für "ORDER BY Startzeit DESC" die gesamte Tabelle gescannt werden. Die DB kann da keine Optimierungen vornehmen.

Dieser Fall schreit förmlich nach einem Index...kommt natürlich auf die Größe der Tabelle an.

[tsteinmaurer]

Dabei ist es wichtig, dass ein absteigender Index angelegt wird. :-D

[ChrisE]

Zitat:

Zitat von mkinzler (Beitrag 1115765)

BTW. SQL-Formatierung geht als Erweiterung des CODE-Tags (=SQL)

THX :thumb:

Zitat:

Zitat von WladiD (Beitrag 1115766)

Dieser Fall schreit förmlich nach einem Index...kommt natürlich auf die Größe der Tabelle an.

Zitat:

Zitat von tsteinmaurer (Beitrag 1115774)

Dabei ist es wichtig, dass ein absteigender Index angelegt wird. :-D

Das heißt, dass wenn ich die älteste Messung und die neueste möchte brauche ich zwei Indizes?

Gruß, Chris

[tsteinmaurer]

Richtig.

MIN => aufsteigender (ASC) Index
MAX => absteigender (DESC) Index

Thomas

[ChrisE]

Danke Euch allen :-)

Ich werde also zwei Indizes anlegen und die Variante

SQL-Code:

SELECT FIRST 1 bla, blub, tralla FROM Messungen ORDER BY Startzeit DESC

bzw

SQL-Code:

...ASC

verwenden.

Bleibt nur noch die Frage ob man noch noch schneller bekommt mit einer SP?

Gruß, Chris

[WladiD]

Zitat:

Zitat von ChrisE (Beitrag 1115786)

Bleibt nur noch die Frage ob man noch noch schneller bekommt mit einer SP?

Das wird sicherlich um einige Tausend CPU-Takte schneller, da das Parsen der Query entfällt. Aber den Performancegewinn wirst du nicht messen können :wink:

Fazit: Das lohnt sich nicht.

[ChrisE]

Zitat:

Zitat von WladiD (Beitrag 1115789)

Fazit: Das lohnt sich nicht.

Danke :thumb:

Gruß, Chris

[FredlFesl]

Zitat:

Zitat von tsteinmaurer (Beitrag 1115782)

Richtig.

MIN => aufsteigender (ASC) Index
MAX => absteigender (DESC) Index

Thomas

Echt? Ich muss doch beim Index für MIN bzw. MAX nur den ersten oder letzten Eintrag nehmen. Beide sind gleich schnell zu erhalten... I

[tsteinmaurer]

Echt. :-D

Probier einfach mal aus: Erstelle dir eine Tabelle mit einem Feld und führe dann aus:

- MIN und MAX ohne Index
- MIN und MAX bei Existenz eines aufsteigenden Index
- MIN und MAX bei Existenz eines absteigenden Index
- MIN und MAX bei Existenz beider Indizes

Welche Ausführungspläne werden für die 4 Varianten gewählt?

[FredlFesl]

Ach, ich sehe gerade: Firebird. Na dann is klar.

MSSQL z.B. ist das schlauer

[DeddyH]

Was hat das mit schlauer zu tun? Wenn ich z.B. eine absteigend sortierte Zahlenliste habe und möchte den kleinsten Wert ermitteln, muss ich die gesamte Liste durchlaufen, da er ja logischerweise ganz am Ende steht. Brauche ich den größten Wert, bekomme ich den quasi sofort. Genauso verhält es sich natürlich äquivalent andersherum.

[tsteinmaurer]

Die Sache ist die, dass Firebird keine bidirektionalen Indizes unterstützt, d.h. eine rasche Travesierung von vorne nach hinten und umgekehrt mit nur einem Index.

[Neumann]

Wenn ich mir die SQL-Abfrage von ChristE ansehe, kann die eigentlich nicht funktionieren:

SELECT bla, blub, tralla FROM Messungen WHERE Startzeit = (select MAX(Startzeit) from Messungen)

MAX ist in der WHERE-Klausel nicht erlaubt.

Würde folgendes vorschlagen:

Code:

SET TERM ^ ;

CREATE OR ALTER PROCEDURE TESTP 
returns (
    pdatum timestamp,
    pWert integer)
as
declare variable adatum timestamp;
begin
  /* Procedure Text */
  select max(datum) from Messungen into :adatum;
  for select datum, wert from Messungen  where datum = :adatum into :pdatum ,:pwert do
  suspend;
end^

SET TERM ; ^

Das for select braucht man, da mehrere Datensätze zurückgeliefert werden könnten. Will man nur einen Datensatz, kann man z.B. noch eine Abfrage nach der max(ID) zwischenschalten und die dann in der letzten where-Klausel benutzen.

Ein Test mit IBExpert und rund 19000 Datensätzen sowie 5 Ergebniszeilen dauert weniger als eine halbe Sekunde, das Ergebnis ist praktisch sofort da.

[DeddyH]

Wo steht denn MAX in der WHERE-Klausel? Das MAX gehört zum Subselect und ist dort durchaus erlaubt.

[mkinzler]

Sonst müsste es in die HAVING-Klausel

[tsteinmaurer]

@Ralf: MAX ist im Subselect und durchaus erlaubt. Bzgl. Performance. 19.000 Datensätze würde ich nicht für Performancemessungen hernehmen. Das sind Peanuts. Interessanter wirds im Millionenbereich.

[Neumann]

Ja stimmt, hab es noch mal probiert. Beim 1. Versuch hat IBExpert das angemeckert. Scheint aber etwas langsamer zu sein als die SP, eine genaue Messung habe ich leider nicht.

Mit 850000 Datensätzen komme ich mit beiden Varianten auf rund 5 s.

[tsteinmaurer]

Ich nehme mal an, ohne Indizes?

[Neumann]

Richtig, auf Datum ist kein Index gewesen. Mit Index etwa die halbe Zeit.

[tsteinmaurer]

Ok, dann wieder etwas zurück im Thread. Hast auch einen absteigenden Index angelegt, weil sonst muss er beim MAX(...) einen Full-Table-Scan machen.

[tsteinmaurer]

@ChrisE: Da Firebird 2.5 eingesetzt wird, kann man natürlich auch die Trace API dazu verwenden, um Flaschenhälse rauszufinden. Siehe auch folgendes Video: http://www.iblogmanager.com/download...tural_scan.htm

[Neumann]

Mit descending wird es noch schneller, dann weniger als 1 s

[ChrisE]

Zitat:

Zitat von tsteinmaurer (Beitrag 1115936)

@ChrisE: Da Firebird 2.5 eingesetzt wird, kann man natürlich auch die Trace API dazu verwenden, um Flaschenhälse rauszufinden. Siehe auch folgendes Video: http://www.iblogmanager.com/download...tural_scan.htm

Cool - das schau ich mir gleich mal an, danke :-)

Zitat:

Zitat von Neumann (Beitrag 1115937)

Mit descending wird es noch schneller, dann weniger als 1 s

Danke für die Tests - ich habe ähnliche Ergebnisse erhalten. Die zwei Indizes reisen es :thumb:

Gruß, Chris