Select Optimierung bei Tabelle mit 15.Mio Datensätzen

[p80286]

Zitat von mika:

Code:

  sqlZielLog.SQL.Add('SELECT');
  sqlZielLog.SQL.Add('  *');
  sqlZielLog.SQL.Add('FROM');
  sqlZielLog.SQL.Add('  ZielLog');
  sqlZielLog.SQL.Add('WHERE');
  sqlZielLog.SQL.Add('  zl_date between '''+FormatDateTime('YYYY-MM-DD', FromTime)+''' AND '''+FormatDateTime('YYYY-MM-DD', ToTime)+'''');
  sqlZielLog.SQL.Add('  AND zl_time between '''+FormatDateTime('HH:NN:SS', FromTime)+''' AND '''+FormatDateTime('HH:NN:SS', ToTime)+'''');
  sqlZielLog.SQL.Add('ORDER BY');
  sqlZielLog.SQL.Add('  zl_date, zl_time');

Hier würde ich an Deiner Stelle.SQL.Text:='select.......' benutzen, das ist meiner Meinung nach übersichtlicher.
Die Datums bzw. Zeitübergabe solltest Du mit Parametern bewerkstelligen.

Zitat von mika:

Code:

  if sqlZielLog.Active then      {----- Warum? }
  begin
    ndx := 0;
    sqlZielLog.last;    {----- Warum? }
    while not sqlZielLog.Eof do
    begin
      Inc(ndx);
      New(sDaten);
      sDaten.Datum := sqlZielLog.FieldByName('zl_date').AsDateTime;
      sDaten.Transponder := sqlZielLog.FieldByName('zl_transpondernr').AsString;
      sDaten.Schlachtnummer := sqlZielLog.FieldByName('zl_schlachnummer').AsString;
      Schlachtdaten.Add(sDaten);
      sqlZielLog.Next;
      if (ndx mod 50) = 0 then
        Application.ProcessMessages;   {----- Warum? }
    end;
    sqlZielLog.Close;

Und wie vorher schon angemerkt, Du solltest nicht mehr Daten über die Leitung schicken als nötig!

Um "die Tabelle möglichst wenig zu stören?" gäbe es vllt. die Möglichkeit das Ergebnis der Datumsabfrage in eine temp. Tablelle auszulagern?

Gruß
K-H

[mika]

Hallo

Das .Active ist dafür das falls der Open Befehl fehlschlägt, das soll schon so...
Das .last war wegen nem test, das ist falsch hier ^^
Das ProcessMessages ist auch nur solange ich teste dadrin

Das auslagern in eine temporäre Tabelle wäre möglich.

[Neumann]

Hallo,

bin zwar mit Advantage nicht so vertraut, würde es so angehen:

Code:

SELECT * FROM ZielLog WHERE zl_date between :DA AND :DE AND zl_time between :TA AND :TE ORDER BY zl_date, zl_time

DA usw als Parameter (Firebird-Systax)

Ein DateTime-Feld anstatt Date und Time würde die Sache übrigens deutlich vereinfachen.

Weiter würde ich für die Query persistente Felder anlegen, ist schneller als FieldByName, was in der Schleife doch oft aufgerufen wird.

Dann habe ich noch die Erfahrung gemacht, dass bei Berechnungen, die Teile von großen Tabellen umfassen, es oft sehr viel schneller geht wenn man den Bereich in eine temporäre Tabelle kopiert und dann die Berechnungen mit der temp. Tabelle macht, wie schon vorgeschlagen.

[p80286]

Zitat von Neumann:

Weiter würde ich für die Query persistente Felder anlegen, ist schneller als FieldByName, was in der Schleife doch oft aufgerufen wird.

Könntest Du das einmal erläutern oder ein Beispiel zeigen?
Wenn ich mich richtig erinnere steht in der Hilfe, daß .FieldbyName die schnellste Möglichkeit wäre an die Daten zu kommen.
(Unterschiede hab ich allerdings noch nicht bemerkt)

Gruß
K-H

[DeddyH]

http://fgaillard.com/2010/11/fieldby...-to-be-honest/

[mika]

Zitat von DeddyH:

http://fgaillard.com/2010/11/fieldby...-to-be-honest/

mit dem tipp aus dem link:
Iterieren der ZielLog-Daten: 815,6767 ms.;

mit fieldbyname:
Iterieren der ZielLog-Daten: 890,5021 ms.;


gruß, mika

[mika]

Alles klar, ich denke ich lasse das jetzt so. Danke an euch alle für eure Hilfe !

[FredlFesl]

Du hast noch nicht geschrieben, das Du das 'ORDER BY' weggelassen hast.

Außerdem vermutest Du nur, dass der enorme Zeitgewinn beim weglassen der Zeit-Klausel im WHERE-Teil auf der Clientseite wieder kompensiert wird. Versucht hast Du es offensichtlich noch nicht. Ein TDataset ist zwar nicht sonderlich flott, aber über 10.000 Records in weniger als 6 Sekunde lokal zu iterieren, sollte flott sein.

Bringt es etwas, die beiden WHERE-Klauseln zu vertauschen? Einige RDBMS optimieren das, andere nicht.

Unterm Strich finde ich das Verhalten von dieser Datenbank aber sehr merkwürdig, bei lächterlichene 10.000 vs. 800 Records so lange zu brauchen, zumal ein Index verwendet wird.

[mika]

Hallo,


ich teste grade die verschiedenen Zugriffszeiten aus, dabei messe ich die ausführung des sqls ebenso wie die zeiten die ich brauche um die datensätze durchzugehen. Das mit dem Order By muss ich noch ausprobieren aber ich hätte die schon gerne geordnet vorliegen.

Soweit wie es jetzt aussieht werde ich die Zeit Klausel im Where wegfallen lassen und das selber prüfen, es scheint recht performant zu sein...

Und nur die Ergebnismenge sind 10.000 Datensätze... ^^ In der Tabelle liegen ein paar mehr vor (siehe Titel dieses Threads)...
Aber ich glaube ich werde das so lassen das ich einfach die Daten eines Tages hole und die Zeiten dann in der Schleife prüfe...

Code:

SELECT * FROM ZielLog WHERE zl_date = '2011-10-01'

Öffnen der ZielLog-Daten: 11,7297 ms.
Anzahl ZielLog-Daten: 17280
Iterieren der ZielLog-Daten: 836,6813 ms.
Davon sind 721 Datensätze in dem von mir gesuchten Zeitraum, die ich in meine Liste gespeichert hab.

Sieht mir annehmbar aus bis jetzt.... ca 0,85 Sekunden für die entnahme der mir wichtigen Daten der Tabelle vom öffnen bis zum schliessen

--edit:

unterschied (2x gemessen) mit und ohne order by ^^:
Mit Order By
Öffnen der ZielLog-Daten: 2334,4217 ms.
Öffnen der ZielLog-Daten: 2324,6134 ms.;

Ohne Order By
Öffnen der ZielLog-Daten: 13,0694 ms.;
Öffnen der ZielLog-Daten: 2,8676 ms.;

[yörsch]

Die Datenbank kenne ich, wir benutzen die nur für wenige hundert Einträge... dageht´s schnell...
Es ist halt keine Oracle oder so...

Kannst du StordProcedures einsetzten? Die sind immer schneller.
Da kann man auch mit # schnell mal ne´Temporäre Tabelle erstellen...

Ich würd erst nach dem Datum selektieren, alles in eine Temporäre Tabelle schieben
und dann weiter mit der Uhrzeit suchen...

Und wenn die Datenbank nicht vollig FIX ist : Indiezes können einen select auch langsamer machen...
Da würd ich auch mal rum spielen...