SELECT beschleunigen

Nico80 · Beiträge: 39 WIN XP DELPHI 2006

Hallo an alle ADO-Spezialisten,

wie kann man eine Suche nach einem bestimmten DS noch beschleunigen...

Benutze zur Zeit ein TADODataset und MS SQL Server 2005 Express.

Rufe diese Funktion 1000x auf und brauche dafür 4 Sek.
Kann ich das noch drücken durch spezielle Einstellungen oder sonst wie?
Danke für die Tips.

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:

function TDBADO.Select(Id: Integer): TDataRec;
begin
  Result := nil;
  if (not FKscDataSetSelect.Prepared) then begin
    FDataSetSelect.Close;
    FDataSetSelect.CommandText := 'SELECT * FROM table_test where id=:id';
    FDataSetSelect.Prepared := True;
  end;

  FDataSetSelect.Close;
  FDataSetSelect.Parameters.ParamByName('id').Value := Id;
  FDataSetSelect.Open;

  if (not FDataSetSelect.IsEmpty) then begin
    Result := TDataRec.Create;
    Result.Id         := Id;
    Result.Name       := FDataSetSelect.FieldValues['name'];
    Result.Number     := FDataSetSelect.FieldValues['number'];
    Result.LastUpdate := FDataSetSelect.FieldValues['lastupdate'];
  end;
  FDataSetSelect.Close;
end;

Agawain · Beiträge: 460 win xp D5, MySQL, devxpress

Hi

eine Möglichkeit wäre die Eigenschaft autoprepared im OI auf true zu setzen, bzw.
die vorbereitenden Arbeiten ausserhalb der Funktion anzusiedeln.
Sparst Dir halt ein 1000 if-Vergleiche.
Auch einer der Close-Aufrufe ist überflüssig.

Darüberhinaus könnte man auch noch über eine stored procedure nachdenken.
Hab mal gelesen, daß die noch ein tick schneller sind.
Bei bei komplexeren Abfragen kann ich mir das sehr gut vorstellen, da sicher jede Datenbank da ihre eigenen Optimierungen hat.

/edit Inzwischen nachgelesen...Vorteile von Stored prodedure sind vor allem Syntaxcheck fällt flach und das Statement liegt dann bei den meisten Datenbanken breits in kompilierter Form vor...also wenn Du die vorbereitenden Arbeiten auslagerst, müßte das fast dem prepared entsprechen...bzw. nur geringe Vorteile haben...käme natürlich drauf an, wie oft die Funktion während des Lebenszyklus des Programms aufgerufen wird, für nur einmal wärs mir wurscht.
Netzwerk-Traffic geht auch noch runter...meistens
In einer Multi-User-Umgebung mit komplexen Abfragen lohnt es sich auf jeden Fall.
Nachteil von stored procedures ansich keine, ausser, dass wenn die Abfragen Berechnungen ausführen, die andernfalls client-seitig ausgeführt würden...kann das den DB-Server in die Knie zwingen.
Naja und vielleicht ein wenig mehr Aufwand für den Programmierer.
/end edit

Ob es hier was bringt kann ich nicht beurteilen, da ich mit stored procedures noch nie gearbeitet habe.

Aber Versuch macht schließlich kluch :wink:

Kannst ja mal schreiben, welche Geschwindigkeitsvorteile du erzielt hast, würd mich mal interessiern.

/edit
Wenn ADO sowas wie ein MEMDatSet unterstützt, könnte das auch noch Vorteile bei Massen-Verarbeitung bringen....einmal alle Daten reinschlürfen...im Speicher bearbeiten und beim zurückschreiben fängt son MemDataset glaub ich an zu streamen, also blockweise zu schreiben, ist natürlich auch gefährlicher...wär mir die Arbeit nicht wert, daß Ganze abzusichern, aber kommt hier halt auf die Anwendung an.

Gruß

Aga

ene · Verfasst: Do 11.10.07 07:12

SP sind schneller als CodeAbfragen. Denn jede mir bekannte DBMS speichert nicht nur die Abfrage, sondern optimiert den Ablauf. Und das nicht nur einmal. Ob deine Abfrage allerdings den Unterschied bemerkt ist fraglich.

Einen weiteren SpeedUp erhält man, wenn man Felder/Parameter nicht mit ihrem Alias, sondern mit ihrer Zahl anspricht.

Ist das eigentlich ein Schleifendurchlauf? Weiß auch nicht, ob man den Recordset als ForwardOnly öffnen kann, aber du durchläufst ihn ja auch gar nicht.

_________________
Wir, die guten Willens sind, geführt von Ahnungslosen, Versuchen für die Undankbaren das Unmögliche zu vollbringen.
Wir haben soviel mit so wenig so lange versucht, daß wir jetzt qualifiziert sind, fast alles mit Nichts zu bewerkstelligen.

BenBE · Verfasst: Fr 12.10.07 13:36

Außerdem solltest Du schauen, inwiefern Du das WHERE weglassen oder anderweitig umformulieren kannst, so dass der Aufwand die Tabelle ständig neu anzufordern entfallen kann.

Wenn Du z.B. einen ganzen BEreich von Abfragen ausführen musst, Dir also die IDs bekannt sind, dann solltest Du gleich WHERE id IN (X,Y,Z) zur Abfrage verwenden und dann die Daten Client-Seitig zuordnen. Auch wenn das öffnen recht schnell geht: JEdes Mal ist ein PUSH und ein ACK notwendig, damit der Server weiß, dass er öffnen soll --> Zeitverlust.

Außerdem zu bedenken: Auf die Art und Weise erhälst Du schnell eine Speicherfragmentierung --> Verlangsamung beim Verwalten der Speicherbereiche.

In welchem Kontext rufst Du die Routine den alles auf? Vielleicht bietet sich das lokale Integrieren in eine andere Funktion mit an?

_________________

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

zuma · Verfasst: Fr 12.10.07 13:52

was genau ist denn 'langsam' ?
Das lesen der Daten aus der DB oder das zuweisen der Daten (ans result oder die Verwendung des Result's vor dem nächsten durchlauf) ?
Neben den genannten möglichkeiten kann man evtl. auch die db 'tunen', in dem man z.B. den wichtigsten Feldern (Abfrage-parameter) einen Index verpasst, statt Select * nur die benötigten Felder aufzählt, usw.

_________________
Ich habe nichts gegen Fremde. Aber diese Fremden sind nicht von hier! (Methusalix)
Warum sich Sorgen ums Leben machen? Keiner überlebts!

Ehemaliges Mitglied Erhaltene Danke: 1

sag mal, weshalb willste denn die abfrage innerhalb von 4 sekunden 1000 mal aufrufen? so schnell kann doch keiner mitlesen.... :roll:

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme