Delphi-PRAXiS
Seite 2 von 2     12   

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Datenbanken (https://www.delphipraxis.net/15-datenbanken/)
-   -   Delphi Performance Problem bei SQL-Abfrage (https://www.delphipraxis.net/75614-performance-problem-bei-sql-abfrage.html)

mkinzler 22. Aug 2006 14:06

Re: Performance Problem bei SQL-Abfrage
 
Zitat:

nein; Ich meinte alle Inserts "zusammensammeln" und mit einem ExecSQL ausführen. Das mit den Values war doch angedacht für jede Zeile der txt-Datei einem Insert, oder?
Nein alle in einem jeweils ein (..) ist ein Werte-Tuppel

Bernhard Geyer 22. Aug 2006 14:07

Re: Performance Problem bei SQL-Abfrage
 
1, (Wie schon angemerkt) sollten passende Indize auf der Tabelle vorhanden sein
2, Alle SELECT + Inserts/Updates werden ja (mit geänderten Werten) sollten als prepared Statements ablaufen (also nur die parameterwerte geändert werden
3, Du solltest halbwegs aktuelle Zeos-Version einsetzen. Ältere Versionen waren krotten-langsam. Falls du das letzte Prozent brauchst entweder ohne komponenten Arbeiten oder MyDAC verwenden.

Damit solltest Du mit lokaler DB überschlagsmäßig alle 10ms ein SQL-Statement abschicken können. Auf ferner DB kommt noch die verzögerungszeiten der Netzwerkkommunikation dazu. Wie hoch sind die Ping-Zeiten zum Server?

Jelly 22. Aug 2006 14:15

Re: Performance Problem bei SQL-Abfrage
 
Wenn es nur 10000 Werte in der Textdatei sind, würd ich den ganzen Bestand erstmal einfach in eine Stringlist laden, oder in eine vielleicht besser geeignete Speicherstruktur, wie auch immer.

Dann wie folgt vorgehen:
Alle IDs (nenn ich jetzt mal die Spalten über die Du testen willst, ob der Record schon in der MySQL Tabelle existiert) suchen, die bereits in der DB vorhanden sind. Dazu baust du dir ein kommaseparated String zusammen, über alle Datensätze im Speicher. Das wird dann sowas:
1,2,3,4,5,...,10000
und führst anschliessend ein select aus, in dem du bestehende Datensätze suchst:
SQL-Code:
select id from deinetable where ID in (1,2,3,4,4,...,10000)
Jetzt durchläufst du deine Stringlist:
ist ID bereits vorhanden -> update Statement für den Record formulieren und zum Server schicken. Updates musst Du leider einzeln abarbeiten.
ist ID noch nicht in der Tabelle drin, dann den Values Tupel, als kommasarated bilden:
(1,'blu'),(2,'bla')...
also neue Datensätze einfach hin anhängen.

Zum Schluss noch ein letztes Insert in die Tabelle:
SQL-Code:
insert into deinetable (ID,Spalte2) values (1,'blu'),(2,'bla')...
Das ist imho die schnellste Möglichkeit, neben dem direkten Laden über den Load Befehl von MySQL, falls es denn damit geht.

Hansi 22. Aug 2006 14:32

Re: Performance Problem bei SQL-Abfrage
 
Danke Tom,

So wie Du das schreibst klingt es einleuchtend; so werde ich das auch machen; Mit dem Befehl Load Data infile kann ich dann immer noch testen.

Das mit der Select Abfrage nach allen update Datensätzen ist eine super idee.

ich teste mal...

hoika 22. Aug 2006 16:40

Re: Performance Problem bei SQL-Abfrage
 
Hallo,

kann die 4.1 schon stored procedures (SP) ?
Wenn ja, alle Einträge in eine eigene Tabelle packen (Name: Import ?)

Dann eine SP, die das Eintragen erledigt (also das select -> update/insert).
Falls die Tabelle während des inserts nicht benötigt wird,
könnte man auch die Indizes deaktivieren (alter index idx_bla inactive)
und nach dem insert wieder neuaufbauen (alter index idx_bla active)

Hauptvorteil ist die geringe Netzlast,
es werden nicht 10000 inserts/updates übers Netz gemacht.

Ah ja,
die Tabelle hat natürlich keine Indizes,
und wird mit 10000 inserts gefüttert.
Oder über das load data.

Heiko

Hansi 24. Aug 2006 13:49

Re: Performance Problem bei SQL-Abfrage
 
Jo Baby ... Jo Baby ... Jooo :)

So nachdem ich sämtliche SQL-Abfragen optimiert habe und vorallem auf das "Insert Into ... Values"-Tupel umgestellt habe. Liege ich derzeit nicht mehr bei 3 Inserts pro Sekunde sondern bei ca. bei 250-300 pro Sekunde.

Nochmal Danke Tom!


Alle Zeitangaben in WEZ +1. Es ist jetzt 01:41 Uhr.
Seite 2 von 2     12   

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz