Parameter & Prepared

[Mavarik]

Hallo Zusammen!

Angeblich sollen ja Prepared-Statements schneller sein, als immer neu das Statement zu übergeben, Richtig?

Wenn ich mit Wireshark mit anschaue was zum MySQL-Server übertragen wird ist das immer das gleiche:

"SELECT * FROM MyTable where ID=1"
"SELECT * FROM MyTable where ID=2"
"SELECT * FROM MyTable where ID=3"
"SELECT * FROM MyTable where ID=4"

Egal ob ich

Delphi-Quellcode:

fdQuery1.SQL.Text := 'SELECT * FROM MyTable where ID=:ID'
fdQuery1.ParamByName('ID').Value := i;

oder

Delphi-Quellcode:

fdQuery1.SQL.Text := 'SELECT * FROM MyTable where ID='+inttostr(I);

Wo ist der Trick?

Mavarik

[Bernhard Geyer]

Der Trick liegt daran auch wirklich prepared Statements zu verwenden.
So wie du es getestet hast, hast du nur Parameter verwendet.

Delphi-Quellcode:

fdQuery1.SQL.Text := 'SELECT * FROM MyTable where ID=:ID'
fdQuery1.Prepare
...
fdQuery1.ParamByName('ID').Value := i;

[Uwe Raabe]

Nur zur Kontrolle: ResourceOptions.DirectExecute ist false?

[Mavarik]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1284190)

Der Trick liegt daran auch wirklich prepared Statements zu verwenden.
So wie du es getestet hast, hast du nur Parameter verwendet.

Delphi-Quellcode:

fdQuery1.SQL.Text := 'SELECT * FROM MyTable where ID=:ID'
fdQuery1.Prepare
...
fdQuery1.ParamByName('ID').Value := i;

Hatte ich...

[Mavarik]

Zitat:

Zitat von Uwe Raabe (Beitrag 1284191)

Nur zur Kontrolle: ResourceOptions.DirectExecute ist false?

Gute Frage was ist Default?

Hast Du vielleicht ein mini Beispiel?

[Uwe Raabe]

Zitat:

Zitat von Mavarik (Beitrag 1284193)

Zitat:

Zitat von Uwe Raabe (Beitrag 1284191)

Nur zur Kontrolle: ResourceOptions.DirectExecute ist false?

Gute Frage was ist Default?

Default ist schon false. Ich wollte das nur als mögliche Fehlerquelle ausschließen.

[Dejan Vu]

Wieso sollte dieses Pillepallestatement mit einem Prepare eigentlich schneller werden?
Wäre es denkbar, das der Prepare-Entscheid-O-Mat einfach meint: "Nö, also so nich?".

Versuchs doch mal mit einem Kombinierten SELECT mit JOIN und statischen WHERE, á la:

Code:

SELECT foo 
  FROM Tabelle1 join Tabelle2 on ...
 where irgendwas and noch irgendwas
   and Foo = :Parameter

Ich denke, wenn da das Prepare nicht zuschlägt, weiß ich auch nicht.

[Bernhard Geyer]

Zitat:

Zitat von Mavarik (Beitrag 1284192)

Hatte ich...

Dann macht Firedac hier was falsch oder ein Property ist falsch gesetzt.

Letztendlich solltest du das sehen was bei Oracle für MySQL und Prepared Statements beschrieben ist:
http://dev.mysql.com/doc/refman/5.0/...tatements.html

[Bernhard Geyer]

Zitat:

Zitat von Dejan Vu (Beitrag 1284199)

Wieso sollte dieses Pillepallestatement mit einem Prepare eigentlich schneller werden?

Auch solche "Pillepallestatements" sind schneller. Ein paar weniger Bytes auf der Netzwerkstrecke, Keine Analyse des SQL-Statements, Kein Aufbau eines optimale Abfrage, ...

Zitat:

Zitat von Dejan Vu (Beitrag 1284199)

Wäre es denkbar, das der Prepare-Entscheid-O-Mat einfach meint: "Nö, also so nich?".

Bei einem Preparen darf hier keiner was entscheiden. Ich sage ihm "Prepare es". Und dann muss es prepared werden. Obwohl. MySQL gehört ja mittlerweile zu Oracle.
Und was für einen Mist wir mit Oracle schon erlebt haben ... (das ist aber andere Geschichte).

Zitat:

Zitat von Dejan Vu (Beitrag 1284199)

Versuchs doch mal mit einem Kombinierten SELECT mit JOIN und statischen WHERE, á la:

Ich denke das o.g. Beispiel ist nur ein Beispiel um zu verstehen wie Prepared Statements funktionieren.

[Mavarik]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1284201)

Ich denke das o.g. Beispiel ist nur ein Beispiel um zu verstehen wie Prepared Statements funktionieren.

Logisch, ich bin aber davon ausgegangen, dass dann auch nur der Parameter neu übertragen wird...

[Dejan Vu]

War ja nur ne Idee. Mal sehen, woran es liegt.

[EgonHugeist]

Hmmm

Meine Frage wäre, ob FD tatsächlich die MySQL-Prepared-stmt API nutzt oder nicht:
http://dev.mysql.com/doc/refman/5.0/...-problems.html
Die API ist buggy seit v4.1!

Des weiteren bietet MySql keine API die Parameter und deren Eigenschaften "sicher" zu hinterfragen:
http://dev.mysql.com/doc/refman/5.0/...-metadata.html
Die Funktion existiert auch schon ewig und tut nix, rein gar gar nix!

Wir bei Zeos haben den Support drin, meine Benchmarks mit dem "real"-prepared Sch.. sind ehrlich gesagt ernüchternd ausgefallen, da bei Parameter-Typ oder Größen-Änderungen immer wieder neue bind+ReAllocMem(wenn der parameter mehr Speicher braucht) notwendig sind. Tatsächlich ist MySQL so 'ne kleine Ausnahme und wirklich Höllen schnell, was das Parsen der Strings und "escapen" angeht.

Der Weg rückwärts als fetch fällt da genauso schlimm aus. Die C-API bietet ResultSets ebenfalls an. Der Performance-Drop ist wirklich übel auch das Speicher handling für Lob's.
Hat jemand eine Ahnung in welcher Art MySQL seine Daten ablegt? String oder Binär (e.g. Ordinals, Floats etc.)?
Und weil wir schon dabei sind: PG bietet seit v8.0 auch ein binär Protokol, doch wie legt PG seine Daten ab? Könnte da was zu holen sein? Fürchte 'ne menge Zeit für die gleiche Pusteblume zu investieren...

Ist eigentlich 'ne dumme Frage, aber Zahlen Lügen halt nicht! Ich kanns mir nicht anders erklären.. Bei PG würde es mich nicht mal wundern, wenn die unendliches String-Parsing innerhalb der Tabellen betreiben.

By default nutzt Zeos die Emulierung der Parameter und bis heute ist diese schneller (wenn man alles drauf trimmt, mal vom Delphi-Unicode-Gedöhns abstand hält und ein paar schneller RTL-Replacements einbaut), und wie voran geführt: sicherer.

Michael

Ahh noch etwas, bevor ich korregiert werde (worauf Bernhard verweist) diese "Prepare xxxx" etc. Syntax hatte ich auch schon durch gespielt. Vielleicht habe ich mich da zu dumm angestellt, doch meine Messungen, aufgrund der vielen call's, fiehlen noch negativer aus...

Somit würde ich mich im Fall MySQL Mavarik anschließen und einfach mal alles in Frage stellen (wenn FD auch emuliert, natürlich und keine "strings" escaped werden müssen)! :)