Firebird Leistung Index Max

[haentschman]

Guten Morgen alle...

Ich hätte da gern mal ein Verständnisproblem...

Gegebenheiten:

Tabelle mit 21 Mio Datensätzen

Delphi-Quellcode:

CREATE TABLE T_RECORD_DATA (
    F_PARAMETER_ID    ID /* ID = INTEGER NOT NULL */,
    F_TIMESTAMP_UNIX  INTEGER_NORMAL /* INTEGER_NORMAL = INTEGER NOT NULL */,
    F_POWER_STATE     INTEGER_NORMAL /* INTEGER_NORMAL = INTEGER NOT NULL */,
    F_VALUE           STRING10 /* STRING10 = VARCHAR(10) NOT NULL */

Indizies

Delphi-Quellcode:

ALTER TABLE T_RECORD_DATA ADD CONSTRAINT FK_T_RECORD_DATA_1 FOREIGN KEY (F_PARAMETER_ID) REFERENCES T_DEVICE_PARAMETERS (ID) ON DELETE CASCADE ON UPDATE CASCADE;

CREATE INDEX T_RECORD_DATA_IDX1 ON T_RECORD_DATA (F_TIMESTAMP_UNIX);

... alle Datensätze bei bestehendem Index eingefügt.

SQL
select first 10 * from T_RECORD_DATA where F_timestamp_unix = (select max(F_timestamp_unix) from t_record_data) Problem:
Ausführungszeit = 36s 926ms ... absolut inakzeptabel

Leistungsanalyse:
siehe Bild und

Delphi-Quellcode:

------ Leistungsinformation ------
Prepare time = 31ms
Ausführungszeit = 36s 926ms
Avg fetch time = 3.692,60 ms
Current memory = 17.699.664
Max memory = 17.901.376
Memory buffers = 1.024
Reads from disk to cache = 82.953
Writes from cache to disk = 0
Fetches from cache = 43.527.070

Die Frage:
Warum greift der Index nicht? Wo ist der Denkfehler?

[mjustin]

Wie sieht der PLAN aus?

Wie ändert sich das Ergebnis wenn die Abfrage auf zwei Statements aufgeteilt wird?

Code:

1. select max(F_timestamp_unix) from t_record_data)
2. select first 10 from T_RECORD_DATA where F_timestamp_unix = :F_timestamp_unix_aus_1

[haentschman]

Danke...

Sooo...
SQL mit festem Wert
select first 10 * from T_RECORD_DATA where F_timestamp_unix = 1398999942

Delphi-Quellcode:

------ Leistungsinformation ------
Prepare time = 31ms
Ausführungszeit = 0ms
Avg fetch time = 0,00 ms
Current memory = 17.733.168
Max memory = 18.122.312
Memory buffers = 1.024
Reads from disk to cache = 0
Writes from cache to disk = 0
Fetches from cache = 27

SQL Max
select max(F_timestamp_unix) from t_record_data

Delphi-Quellcode:

------ Leistungsinformation ------
Prepare time = 31ms
Ausführungszeit = 41s 559ms
Avg fetch time = 41.559,00 ms
Current memory = 17.726.240
Max memory = 18.122.312
Memory buffers = 1.024
Reads from disk to cache = 82.949
Writes from cache to disk = 0
Fetches from cache = 43.527.043

Also der Flaschenhals wäre gefunden. Da müßte aber der Index doch auch greifen oder?

[jobo]

Ich hab keine Ahnung wie/ob Firebird irgendwas Richtung Statistikanalyse macht.
Wenn ja, vielleicht nicht fertig geworden vor der ersten Abfrage, also im weitesten Sinne falsche, schlechte Statistiken.
Wenn nein, wenn die Werte in order of appearance in den Indexaufbau gehen ("bei bestehendem Index eingefügt.."), kann je nach internen Verfahren ein "schlechter " Index entstehen.
Unabhängig von allem zuvor genannten kann einfach der Inhalt des Feldes ungeeignet sein, viele gleiche Werte, sodass am Ende ein Fullscan daraus wird.
Da Du "select top 10" machst, scheint ja allein das Maximum schon relativ häufig vorhanden zu sein, so dass Du es einschränkst. Oder erhoffst Du Dir davon einfach nur den Server etwas zu schonen?

[jobo]

Zitat von haentschman:

Danke...

SQL Max
select max(F_timestamp_unix) from t_record_data

Delphi-Quellcode:

------ Leistungsinformation ------
Prepare time = 31ms
Ausführungszeit = 41s 559ms
Avg fetch time = 41.559,00 ms
Current memory = 17.726.240
Max memory = 18.122.312
Memory buffers = 1.024
Reads from disk to cache = 82.949
Writes from cache to disk = 0
Fetches from cache = 43.527.043

Also der Flaschenhals wäre gefunden. Da müßte aber der Index doch auch greifen oder?

Sorry, über rot gefahren.
Das ist schon mal was, aber kein Ausführungsplan.

[haentschman]

Danke an alle erst mal.

Gerade gefunden:
http://www.firebirdfaq.org/faq205/

Zitat:

Why doesn't MAX(Primary key field) use index?

It's because primary keys are enforced using ascending index and MAX only uses descending index. For example, if you try to get MIN(PK) it would use the index. If you often have queries using MAX, it is a good idea to create another, DESCENDING index on PK column.

Toll zu wissen...

Nach der Änderung und Neuberechnung des Index:
SQL
select max(F_timestamp_unix) from t_record_data

Delphi-Quellcode:

------ Leistungsinformation ------
Prepare time = 31ms
Ausführungszeit = 0ms
Avg fetch time = 0,00 ms
Current memory = 17.897.528
Max memory = 70.260.896
Memory buffers = 1.024
Reads from disk to cache = 5
Writes from cache to disk = 0
Fetches from cache = 9

Das hat mich einen ganzen Tag gekostet.

Danke für die Tipps zum Brille putzen.

Zitat:

Da Du "select top 10" machst, scheint ja allein das Maximum schon relativ häufig vorhanden zu sein, so dass Du es einschränkst. Oder erhoffst Du Dir davon einfach nur den Server etwas zu schonen?

... in diesem Falle existieren je Timestamp zwischen 13 und 30 Parameter. War eher auch zum Testen.

[Union]

Ginge es nicht auch so (ob das dann schneller wäre ist eine andere Frage):

Code:

select first 1 skip ((select count(*)-1 from T_RECORD_DATA)) F_timestamp_unix from T_RECORD_DATA order by F_timestamp_unix

[haentschman]

Zitat:

------ Leistungsinformation ------
Prepare time = 31ms
Ausführungszeit = 1m 34s 630ms
Avg fetch time = 94.630,00 ms
Current memory = 17.634.080
Max memory = 74.215.232
Memory buffers = 1.024
Reads from disk to cache = 165.900
Writes from cache to disk = 0
Fetches from cache = 87.054.086

doch wohl nicht schnell. Macht nix.

[tsteinmaurer]

Firebird hat keine bi-direktionalen Indizes, darum brauchst du einen DESCENDING Index um ein MAX daraus bedienen zu können.

[haentschman]

Das hab ich auch nun schmerzlich festgestellt.
Für MIN gilt natürlich das ganze umgekehrt. Wie sieht die Konstellation für COUNT aus? Welche Variante greift da am besten? Der IBExpert zählt sich immer einen Wolf wenn ich mal zählen lasse.