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...